Re: Charm Store policy updates and refinement for 2.0

[Antonio Rosales]

On Fri, Mar 18, 2016 at 1:28 PM, Charles Butler
 wrote:
> Big +1 to the categories
>
> What i'd like to see is the policy document move to strong language where we
> can build tooling around the automated checking of policy.
>
> Refactoring the MUSTS and SHOULDS give us a strong lead on that language.
> MUST == has to be satisfied
> SHOULD = area for improvement - (proper use of warn, which wont fail charm
> proof for a change)
>
> eg: We require OSI approved licenses, we can scan the copyright file for
> that with a license bot to find the lingo of approved licenses, otherwise it
> flags for human review. It may be an acceptable license we're not aware of.
>
> The more points in policy we can convert to strongly typed lingo, the more
> targeted and automated we can make portions of policy review, and also
> scopes the mission of ~charmers. A limited resource who is responsible for
> enforcing this document.

Strongly agree. The more binary we make the policy the easier it is
for folks to understand what the need to accomplish to get it
recommended. Plus, it mapd lingo, the more
> targeted and automated we can make portions of policy review, and also
> scopes the mission of ~charmers. A limited resource who is responsible for
> enforcing this document. os well to review queue check list.  Thus in that 
> vein
- Consider dropping the "Must" from the "General Guidelines" as some
point are very objective there.
- Reference Fuctional Testing in the Deployment section
- We should be explicit for the items typically called out that are
needed in readmes, ie steps to smoke test, config options to set,
relations to set, upstream links, and how to get the software

I'll propose a branch with above suggestions, but thought I should
also mail here.

-thanks,
Antonio


>
>
>
> On Fri, Mar 18, 2016 at 11:59 AM Jorge O. Castro  wrote:
>>
>> Hello everyone,
>>
>> With 2.0 around the corner we decided to spend some time cleaning up
>> the page everyone loves to hate, the Juju Charm Store policy:
>>
>> https://jujucharms.com/docs/1.25/authors-charm-policy
>>
>> and here is what I would like to propose:
>>
>>
>> https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md
>>
>> I've done a few things here:
>>
>> - I've separated it from one huge paragraph to sections, General,
>> Testing and Quality requirements, Metadata requirements, and Security
>> requirements.
>> - I've split out things that a charm/bundle MUST do and what it SHOULD
>> do in each section to make it clearer on what is a hard requirement
>> and what is a recommendation.
>> - I've removed most of the Ubuntu-specific jargon and generalized it
>> to include other OSes such as CentOS.
>> - Made documenting interfaces and external dependencies a requirement.
>>
>> There are also some new policies that we need ack from ~charmers in
>> order to implement. Specifically we've made the testing and quality
>> requirements explicit. I've also added a requirement of using Juju
>> Resources (which appears to be undocumented?) for payloads.
>>
>> Recommendations from everyone on what we should include here would be
>> most welcome, specifically our recommendations around Windows charms
>> is non-existent.
>>
>>
>> --
>> Jorge Castro
>> Canonical Ltd.
>> http://jujucharms.com/ - The fastest way to model your service
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 
Antonio Rosales
Ecosystem Engineering
Canonical

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Mark Shuttleworth]

On 20/03/16 20:21, roger peppe wrote:
> If the released Juju 2.0 uses v5 of the charmstore API (which it will
> soon hopefully anyway when my branch to support the new publishing
> model lands), then there's a straightforward solution here, I think:
> change v4 of the charmstore API to refuse to serve min-juju-version
> charm archives to clients. Since the only v4-using clients should be
> old juju versions, this could provide a reasonably cheap to implement
> and straightforward solution to the problem.
>

+1, good thinking, batman :)

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[roger peppe]

If the released Juju 2.0 uses v5 of the charmstore API (which it will
soon hopefully anyway when my branch to support the new publishing
model lands), then there's a straightforward solution here, I think:
change v4 of the charmstore API to refuse to serve min-juju-version
charm archives to clients. Since the only v4-using clients should be
old juju versions, this could provide a reasonably cheap to implement
and straightforward solution to the problem.

On 18 March 2016 at 09:49, Uros Jovanovic  wrote:
> We’re looking in how we can identify 1.x Juju client/server in such a way
> that at the same time we don’t block access to charms for other clients
> using our HTTP API.
>
>
> On Fri, Mar 18, 2016 at 9:34 AM, Mark Shuttleworth  wrote:
>>
>> On 17/03/16 22:34, Nate Finch wrote:
>> > Yes, it'll be ignored, and the charm will be deployed normally.
>> >
>> > On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner
>> > 
>> > wrote:
>> >
>> >> This is awesome.  What will happen if a charm possesses the flag in
>> >> metadata.yaml and is deployed with 1.25.x?  Will it gracefully ignore
>> >> it?
>> >>
>>
>> I wonder if there is a clean way for us to have Juju 1.x reject the
>> charm very early in the process, giving an error that would essentially
>> amount to the "not understood"? Or if we could have the charm store
>> refuse to serve up the charm to a 1.x Juju client / server?
>>
>> Mark
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Planning for Juju 2.2 (16.10 timeframe)

[roger peppe]

On 16 March 2016 at 12:31, Kapil Thangavelu  wrote:
>
>
> On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth  wrote:
>>
>> Hi folks
>>
>> We're starting to think about the next development cycle, and gathering
>> priorities and requests from users of Juju. I'm writing to outline some
>> current topics and also to invite requests or thoughts on relative
>> priorities - feel free to reply on-list or to me privately.
>>
>> An early cut of topics of interest is below.
>>
>> Operational concerns
>>
>> * LDAP integration for Juju controllers now we have multi-user controllers
>> * Support for read-only config
>> * Support for things like passwords being disclosed to a subset of
>> user/operators
>> * LXD container migration
>> * Shared uncommitted state - enable people to collaborate around changes
>> they want to make in a model
>>
>> There has also been quite a lot of interest in log control - debug
>> settings for logging, verbosity control, and log redirection as a systemic
>> property. This might be a good area for someone new to the project to lead
>> design and implementation. Another similar area is the idea of modelling
>> machine properties - things like apt / yum repositories, cache settings etc,
>> and having the machine agent setup the machine / vm / container according to
>> those properties.
>>
>
> ldap++. as brought up in the user list better support for aws best practice
> credential management, ie. bootstrapping with transient credentials (sts
> role assume, needs AWS_SECURITY_TOKEN support), and instance role for state
> servers.
>
>
>>
>> Core Model
>>
>>  * modelling individual services (i.e. each database exported by the db
>> application)
>>  * rich status (properties of those services and the application itself)
>>  * config schemas and validation
>>  * relation config
>>
>> There is also interest in being able to invoke actions across a relation
>> when the relation interface declares them. This would allow, for example, a
>> benchmark operator charm to trigger benchmarks through a relation rather
>> than having the operator do it manually.
>>
>
> in priority order, relation config

What do you understand by the term "relation config"?

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju 2.0 beta3 push this week

[Ian Booth]

Another feature which will be in the next beta is support for keystone 3 in
Openstack.

On 18/03/16 04:51, Rick Harding wrote:
> tl;dr
> Juju 2.0 beta3 will not be out this week.
> 
> The team is fighting a backlog of getting work landed. Rather than get the
> partial release out this week with the handful of current features and
> adding to the backlog while getting that beta release out, the decision was
> made to focus on getting the current work that’s ready landed. This will
> help us get our features in before the freeze exception deadline of the
> 23rd.
> 
> We have several new things currently in trunk (such as enhanced support for
> MAAS spaces, machine provisioning status monitoring, Juju GUI embedded CLI
> commands into Juju Core), but we have important things to get landed. These
> include:
> 
> - Updating controller model to be called “admin” and a “default” initial
> working model on bootstrap that’s safely removable
> - Minimum Juju version support for charms
> - juju read-only mode
> - additional resources work with version numbers and bundles support
> - additional work in the clouds and credentials management work
> - juju add-user and juju register to sign in the new user
> 
> The teams will work together and focus on landing these and we’ll get a
> beta with the full set of updates for everyone to try out next week. If you
> have any questions or concerns, please let me know.
> 
> Thanks
> 
> Rick
> 
> 
> 

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Usability issues with status-history

[John Meinel]

>
> ...
>


>
> > I really think we want to be putting more status for machine pending
> > progress. Now, as for 100 progress messages, it turns out the rate
> limiting
> > on status updates means we can drop some of them. (we always get 100
> events
> > from LXD, but if we only update Juju with one every 1s, then we generally
> > get a lot fewer if your download speed is fast.)
> >
> > But regardless, having genuine feedback as to what is going on outweighs
> a
> > minor thing about having too much information in the backlog.
> >
>
> Why not have both? Report progress but not persist such data.
>

I'm perfectly happy with that, just pointing out that if we don't change
anything, I'd still rather have the information to give visibility into
what is going on, rather than not have it.

John
=:->
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Usability issues with status-history

[Ian Booth]

On 20/03/16 22:44, John Meinel wrote:
>>
>> ...
>>
>> For the second bug, where a downloading % spams the history, it seems like
>> the easy answer is "don't do that".  For resources, we specifically avoided
>> putting download progress in status history for that very reason.  In the
>> future, it seems like it could be useful to have some mechanism to show
>> transient messages like downloading % etc, but status history does not seem
>> like the appropriate place to do that, especially given how it is currently
>> configured... and it seems way too late to be adding a new feature for 2.0
>>
>> Just my 2 cents.
>>
>> -Nate
>>
> 
> The one aspect here is that it has been a consistent problem, especially
> with the local provider, of people wanting to know why things haven't
> started yet. Being able to give them concrete progress is a huge boon here.

+1 But do we need to persist these transient progress messages. We can still
report progress to the user each time they run juju status, but why save such
data when its value is of limited or minimal value once the download of an image
has finished.

> I really think we want to be putting more status for machine pending
> progress. Now, as for 100 progress messages, it turns out the rate limiting
> on status updates means we can drop some of them. (we always get 100 events
> from LXD, but if we only update Juju with one every 1s, then we generally
> get a lot fewer if your download speed is fast.)
> 
> But regardless, having genuine feedback as to what is going on outweighs a
> minor thing about having too much information in the backlog.
> 

Why not have both? Report progress but not persist such data.

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Usability issues with status-history

[John Meinel]

>
> ...
>
> For the second bug, where a downloading % spams the history, it seems like
> the easy answer is "don't do that".  For resources, we specifically avoided
> putting download progress in status history for that very reason.  In the
> future, it seems like it could be useful to have some mechanism to show
> transient messages like downloading % etc, but status history does not seem
> like the appropriate place to do that, especially given how it is currently
> configured... and it seems way too late to be adding a new feature for 2.0
>
> Just my 2 cents.
>
> -Nate
>

The one aspect here is that it has been a consistent problem, especially
with the local provider, of people wanting to know why things haven't
started yet. Being able to give them concrete progress is a huge boon here.
I really think we want to be putting more status for machine pending
progress. Now, as for 100 progress messages, it turns out the rate limiting
on status updates means we can drop some of them. (we always get 100 events
from LXD, but if we only update Juju with one every 1s, then we generally
get a lot fewer if your download speed is fast.)

But regardless, having genuine feedback as to what is going on outweighs a
minor thing about having too much information in the backlog.

John
=:->


>
> On Sat, Mar 19, 2016, 10:28 AM William Reade 
> wrote:
>
>> On Sat, Mar 19, 2016 at 1:40 PM, Horacio Duran <
>> horacio.du...@canonical.com> wrote:
>>
>>>
>>>
>>>
>>> I think you are attributing too much importance to some data that can
>>> hardly be considered information let me try to mention some points that I
>>> think are valid here.
>>> 1) Not every message is valuable, you state that every message we throw
>>> away makes it harder to debug, but certainly a message like "downloading
>>> N%" is useless, you can record the start of the download and failure/end
>>> but the steps intermediate are quite useless. We can argue later which
>>> messages satisfy this criteria, but I am completely sure that some do.
>>>
>>
>> We only know which messages are useless once we know who's looking at the
>> data and what they're looking for. In MVC terms, the more we delete from
>> the model data, the more we constrain/distort what views we can implement,
>> and hence hamper our own ability to evolve better solutions as we need them.
>>
>> I think this follows from the fact that we *can* argue which messages are
>> useless -- by doing that we're implicitly arguing about what perspectives
>> we want to support. And that's a fine discussion to have, but it's a choice
>> we should make at presentation time, when we have the best possible
>> understanding of what information we're trying to show; and preserving the
>> raw data until that point leaves us, and others, free to implement new
>> views for new use cases without having to write code inside the controller.
>>
>>
>>> 2) Not filling the history buffer with superfluos messages will help
>>> here, although I do agree we should find a more elegant deletion criteria
>>> (time sounds right) while not loosing sight of size (at this point no one
>>> has a record of the actual cost of storing these things in terms of space
>>> therefore we cannot make decisions based on the scale we want to support.
>>>
>>> Regarding "making the charm decide" I agree its something we might not
>>> want to do, I would actually not export this to the charm, I would just use
>>> it internally, since we are opinionated we can very well decide what goes
>>> there.
>>>
>>> Adding more status information will help adding observability, not
>>> having a flag for internal ephemeral statuses strikes me a bit as deleting
>>> with the left hand what you just wrote with the right one (saying might not
>>> translate well from Spanish)
>>>
>>
>> Not having a special delete-this-status flag seems entirely in line with
>> not deleting statuses. Collecting all the data and then deleting bits of it
>> feels much more self-contradictory. Am I missing your point?
>>
>> Finally, can this be a potential shoot in our own foot tool? yes, but so
>>> can almost any other part of our code base, this is something juju will use
>>> to report information to the user therefore we control it and, if we are
>>> not careful we will shot ourselves but, then again, if we are not careful
>>> with almost any part of the code we will do so too.
>>>
>>
>> To continue the gunplay theme: don't saw the barrel off your shotgun just
>> in case you need to rob a bank one day :).
>>
>> Cheers
>> William
>>
>>
>>>
>>> Cheers
>>>
>>> On Thu, Mar 17, 2016 at 6:51 AM, William Reade <
>>> william.re...@canonical.com> wrote:
>>>
>>> I see this as a combination of two problems:

 1) We're spamming the end user with "whatever's in the status-history
 collection" rather than presenting a digest tuned for their needs.

>>> 2) Important messages get thrown away way too early, because we don't
 know which messages are 

Re: Usability issues with status-history

[William Reade]

On Sun, Mar 20, 2016 at 2:51 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> +1 on collapsing repeats. I'd also prefer to add more data to status so
> that we can collapse entries, rather than dropping data so that we
> don't/can't see it in history.
>
> What do we base "sensible filtering" on? Exact match on message isn't
> enough for download messages, obviously, and I'd be very hesitant to bake
> in any knowledge of specific message formats.
>

Yeah, message formats would be a pretty poor basis for similarity.

IIANM, our status entries can carry additional data which we don't render.
> If we add the concept of overarching operations to status entries (e.g.
> each "image download progress" entry is part of the "image download"
> operation), then we could collapse all adjacent entries within that
> operation. This could be a simple string in the status data; or we could
> extend the status schema. Either way.
>

YANM :). I'm pretty sure that adding a value to status data is the easiest
approach; and, given that we can't change all the code at once, I think
it's also better to have the maybe-present value explicitly in the
status-data-bag rather than part of the schema (and hence subtly implied to
be more reliable than it actually is). Thoughts?

Cheers
William
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Warning: test suite not actually isolated

[Anastasia Macmood]

John

Thank you for discovering and working on this!

This sounds like an awful can of worms and should be addressed in a
dedicated manner.

I'll add it to the tech debt board and bug squad board with a reference
to your branch.

I am not sure that anyone on core has a capacity to tackle it right this
second but I am hoping that the bug squad can take it head-on soon \o/

Sincerely Yours,

Anastasia

On 17/03/16 19:43, John Meinel wrote:
> tl; dr: I need some help fixing our tests that are incorrectly not
> isolated from the real world.
>
> So...
>
> In investigating the bug with PatchValue and non pointer receivers, we
> realized that PatchValue calls AddCleanup. Which means that If you are
> doing:
> func ... SetUpSuite() {
>s.PatchValue(, safeFoo)
> }
>
> That PatchValue gets cleaned up in the first TearDownTest().Which
> means that the isolation you thought you were adding to the *Suite* is
> actually isolated only to the first test that gets run.
>
> I have a branch of "juju/testing" that fixes it so AddCleanup can be
> called at any time. If it is called before SetUpTest(), then it adds a
> cleanup to the Suite stack, otherwise it adds it to the current Test
> stack.
>
> But that breaks about 100 tests that weren't as isolated as they
> thought they were.
>
> It also breaks a few tests that were Patching values before calling
> IsolationSuite.SetUpTest/Suite(), eg:
> SetUpTest() {
>   PatchValue()
>   Base.SetUpTest()
> }
>
> My branch that starts working on this is at:
>  g...@github.com:jameinel/juju unsafe-cleanups
>
> One of the big examples of bad tests is "provider/ec2". 52 tests fail
> because they either try to read from cloud-images.ubunt.com
>  directly, or because they try to read
> from test:/streams/v1/index.sjson but don't accept the signature on
> those files.
>
>
> Is anyone able to help me tackle cleaning up our test suite?
>
> Thanks,
> John
> =:->
>
>
>

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charm Store policy updates and refinement for 2.0

[Tom Barber]

Bundles must only use charms which are already in the store, they cannot
reference charms in personal namespaces.

I assume this apples to only bundles that get promoted to recommended
otherwise how would you enforce it?

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 18 March 2016 at 15:58, Jorge O. Castro  wrote:

> Hello everyone,
>
> With 2.0 around the corner we decided to spend some time cleaning up
> the page everyone loves to hate, the Juju Charm Store policy:
>
> https://jujucharms.com/docs/1.25/authors-charm-policy
>
> and here is what I would like to propose:
>
> https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md
>
> I've done a few things here:
>
> - I've separated it from one huge paragraph to sections, General,
> Testing and Quality requirements, Metadata requirements, and Security
> requirements.
> - I've split out things that a charm/bundle MUST do and what it SHOULD
> do in each section to make it clearer on what is a hard requirement
> and what is a recommendation.
> - I've removed most of the Ubuntu-specific jargon and generalized it
> to include other OSes such as CentOS.
> - Made documenting interfaces and external dependencies a requirement.
>
> There are also some new policies that we need ack from ~charmers in
> order to implement. Specifically we've made the testing and quality
> requirements explicit. I've also added a requirement of using Juju
> Resources (which appears to be undocumented?) for payloads.
>
> Recommendations from everyone on what we should include here would be
> most welcome, specifically our recommendations around Windows charms
> is non-existent.
>
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - The fastest way to model your service
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju