Re: Proposal: Charm testing for 2.0

As an aside; is there a good write-up somewhere about charm unit testing. I'd like to do this but I'm not sure how to do this. I am completely new to unit testing so I'm having a hard time to see how a good unittest for a Charm would look like and what exactly should be tested. 2016-03-17 1:52

Re: Usability issues with status-history

On Sat, Mar 19, 2016 at 8:36 PM William Reade wrote: > On Sat, Mar 19, 2016 at 4:39 AM, Ian Booth > wrote: > >> >> I mostly agree but still believe there's a case for transient messages. >> The case >> where Juju is downloading an image and

Re: PatchValue (AddCleanup) unsafe with non pointer receiver test

On 17 March 2016 at 04:52, John Meinel wrote: > I came across this in the LXD test suite today, which was hard to track > down, so I figured I'd let everyone know about it. > > We have a nice helper in testing.IsolationSuite with "PatchValue()" that > will change a global

Re: Charm Store policy updates and refinement for 2.0

On Fri, Mar 18, 2016 at 12:11 PM, Tom Barber wrote: > I assume this apples to only bundles that get promoted to recommended > otherwise how would you enforce it? Yes, to be clear these policies only apply to things that are in the recommended/promulgated space. So

Usability issues with status-history

Machines, services and units all now support recording status history. Two issues have come up: 1. https://bugs.launchpad.net/juju-core/+bug/1530840 For units, especially in steady state, status history is spammed with update-status hook invocations which can obscure the hooks we really care

Re: Planning for Juju 2.2 (16.10 timeframe)

Here's another one, which I can't find in the docs, but apologies if it exists. It would be good to be able to specify allowed origin IPs for juju expose for cloud types that support it. For example in EC2 instead of allowing 0.0.0.0 allow a specific address or range. But also expand that

Charm Store policy updates and refinement for 2.0

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:

Preparing for the next beta - CI runs on feature branches

Hey Everyone! The cutoff for the next beta is just around the corner (Monday, March 21)! In order to meet this cutoff, please pay attention to the CI reports [0] on your branches and address failures on your branch when they arise. To avoid wasting CI test time on branches with known errors, we

Re: Proposal: Charm testing for 2.0

Good evening, I really like the notion of a bundle possessing functional tests as an enhancement to test coverage. I agree with almost all of those ideas. :-) tldr; I would suggest that we consider bundle tests 'in addition to' and not 'as a replacement of' individual charm tests, because:

Re: Charm Store policy updates and refinement for 2.0

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 -

Re: Proposal: Charm testing for 2.0

On Thu, Mar 17, 2016 at 9:08 AM Tom Barber wrote: > Its taken me about 2 weeks of on and off testing to get 4 unit tests > working, getting everything to play ball is hard, so it would be good! > Maybe I'll write a blog post about it once I'm done. > Fantastic! Do you

Re: Charmers application - David Ames

Team - David played a monumental role in resolving a handful of issues I was hitting my head on while trying to solidify my HA Openstack, also with DVR issues which I was experiencing prior. The issues I was experiencing were rather in depth and complex. David went a great deal out of his way to

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

Thanks Nate, great stuff. I know there's a lot of folks looking forward to this helping our charming community out as we fill out the model more and charms get to adapt and move forward. On Thu, Mar 17, 2016 at 6:35 PM Nate Finch wrote: > Yes, it'll be ignored, and the

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

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? > >

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 15:04, Kapil Thangavelu wrote: > Relations have associated config schemas that can be set by the user > creating the relation. I.e. I could run one autoscaling service and > associate with relation config for autoscale options to the relation with a > given

Re: Proposal: Charm testing for 2.0

On Wed, Mar 16, 2016 at 7:52 PM, Marco Ceppi wrote: > Hello everyone! > > This is an email I've been meaning to write for a while, and have > rewritten a few times now. With 2.0 on the horizon and the charm ecosystem > rapidly growing, I couldn't keep the idea to

Unfairly weighted charmstore results

Cross posted from IRC: Hello folks, I have a gripe about the charm store search. Mostly because its really badly weighted towards recommended charms, and finding what you(an end user wants is really hard unless they know what they are doing). Take this example: https://jujucharms.com/q/pentaho

Re: Openstack HA Portland Meetup Present

Thanks for the update James, glad things went so well! From our end, we appreciate the awesome first hand user feedback you're always willing to reach out and provide. Our stuff just gets better with folks like you putting it to the test day in and day out. I can't wait to get you some of the new

Re: Planning for Juju 2.2 (16.10 timeframe)

Couple of new things cropped up today that would be very useful. a) actions within gui, currently its a bit weird to drag stuff around in the gui then drop to shell to run actions. Doesn't make much sense to a user. b) actions within bundles. For example, I'd like a few "standard" bundles, but

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

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

Charmers application

Former ~charmer(s) formally requesting to come back into the fold. In my IS days I was in ~charmers and did work around the charms IS uses the most: apache2, haproxy, nrpe-external-master, cassandra etc. Now in the OpenStack Charmers team I get my hands dirty every day working with the

Re: Proposal: Charm testing for 2.0

I tend to agree with Ryan, I think the ideas are reasonably sound, although I'm not sure about the "every charm should be part of a bundle" policy, but I certainly don't think you should discourage testing at charm level the encapsulation can be useful, and you can never have too many tests! I'm

Re: Unfairly weighted charmstore results

BTW, I reported a very similar problems in this bug: https://github.com/CanonicalLtd/jujucharms.com/issues/192 On Thu, Mar 17, 2016 at 10:18 AM Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Hi Tom, > > We currently bump the recommended charms over the community ones. The > reason other

Re: Usability issues with status-history

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

Re: openstack base/autopilot

Also, the Openstack base package can be used to bootstrap Autopilot. If you install it and run "$ sudo openstack-install" the Autopilot will be one of the options presented to you. - Daniel Sent from my iPhone > On Mar 19, 2016, at 4:58 AM, Mark Shuttleworth wrote: > >> On

Re: Usability issues with status-history

On Sat, Mar 19, 2016 at 4:39 AM, Ian Booth wrote: > > I mostly agree but still believe there's a case for transient messages. > The case > where Juju is downloading an image and emits progress updates which go into > status history is to me clearly a case where we

Re: Usability issues with status-history

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 important. I think

Re: Planning for Juju 2.2 (16.10 timeframe)

On 08/03/16 23:51, Mark Shuttleworth wrote: > *Storage* > > * shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts) > * object storage abstraction (probably just mapping to S3-compatible APIS) > > I'm interested in feedback on the operations aspects of storage. For > example, whether it

Re: Openstack HA Portland Meetup Present

Thanks for the update James, glad things went so well! From our end, we appreciate the awesome first hand user feedback you're always willing to reach out and provide. Our stuff just gets better with folks like you putting it to the test day in and day out. I can't wait to get you some of the new

New feature for charmers - min-juju-version

There is a new (optional) top level field in the metadata.yaml file called min-juju-version. If supplied, this value specifies the minimum version of a Juju server with which the charm is compatible. When a user attempts to deploy a charm (whether from the charmstore or from local) that has

juju versions are now in github.com/juju/version

For a recent change in 2.0, we needed to be able to reference the version.Number struct from both juju-core and charm.v6. In order to support this, we moved most of the contents of github.com/juju/juju/version to at top level repo at github.com/juju/version. Note that certain juju-core-specific

Re: Proposal: Charm testing for 2.0

On Thu, Mar 17, 2016 at 8:38 AM, Marco Ceppi wrote: > On Thu, Mar 17, 2016 at 12:39 AM Ryan Beisner > wrote: > >> Good evening, >> >> I really like the notion of a bundle possessing functional tests as an >> enhancement to test coverage. I

Re: Proposal: Charm testing for 2.0

The observation which might be too basic here is that for an Amulet test to do something useful it needs to exercise the relations. This implies (almost always) another charm. When your testing depends on more than one charm (in what might be a synthetic situation) you are talking about bundles.

Re: Planning for Juju 2.2 (16.10 timeframe)

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

Re: Proposal: Charm testing for 2.0

On Thu, Mar 17, 2016 at 5:39 AM Tom Barber wrote: > I tend to agree with Ryan, I think the ideas are reasonably sound, > although I'm not sure about the "every charm should be part of a bundle" > policy, but I certainly don't think you should discourage testing at charm

Re: Planning for Juju 2.2 (16.10 timeframe)

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

Re: Charm Store policy updates and refinement for 2.0

Cool! -- 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

Re: Proposal: Charm testing for 2.0

On Thu, Mar 17, 2016 at 10:40 AM, Benjamin Saller < benjamin.sal...@canonical.com> wrote: > The observation which might be too basic here is that for an Amulet test > to do something useful it needs to exercise the relations. This implies > (almost always) another charm. When your testing depends

Re: openstack base/autopilot

On 19/03/16 03:58, Frank Ritchie wrote: > Does Openstack Autopilot use the Openstack Base bundle? It uses the same charms, but it has to construct a custom model based on: * choice of hypervisor (KVM, LXD) * choice of storage (object, block, SWIFT, Ceph, ScaleIO etc) * choice of SDN

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

On 17/03/16 18:57, Nate Finch wrote: > There is a new (optional) top level field in the metadata.yaml file called > min-juju-version. If supplied, this value specifies the minimum version of > a Juju server with which the charm is compatible. Thank you! This is an oft-requested feature to enable

Re: Planning for Juju 2.2 (16.10 timeframe)

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

Re: Unfairly weighted charmstore results

Hi Tom, We currently bump the recommended charms over the community ones. The reason other shows is due to using N-grams (3-N) in search and the ranking logic using that puts recommended charms over the non-recommended ones. And we're not only searching over names of charms but a bunch of content

Re: Planning for Juju 2.2 (16.10 timeframe)

Yeah, I guess that would be a good solution for sample data and stuff. Doesn't work for user defined bits and pieces though. For actions we current "cat" the content into a parameter, but of course that doesn't work for everything, and really really sucks when you try and cat unescaped JSON into

Re: Proposal: Charm testing for 2.0

On Thu, Mar 17, 2016 at 12:39 AM Ryan Beisner wrote: > Good evening, > > I really like the notion of a bundle possessing functional tests as an > enhancement to test coverage. I agree with almost all of those ideas. :-) > tldr; I would suggest that we consider

Openstack HA Portland Meetup Present

I just gave this presentation --> http://54.172.233.114/ at an Openstack meetup at puppet headquarters in Portland, geared around HA Openstack production deployments. I wanted to update the team of the great news! It was by far the best presentation I have ever given, which isn't saying much,

Re: Usability issues with status-history

On Thu, Mar 17, 2016 at 8:41 AM, Ian Booth wrote: > > Machines, services and units all now support recording status history. Two > issues have come up: > > 1. https://bugs.launchpad.net/juju-core/+bug/1530840 > > For units, especially in steady state, status history is

Re: juju 2.0 beta3 push this week

Hi! Could I get this bug added to the list too? https://bugs.launchpad.net/juju-core/+bug/1554721 On Thu, Mar 17, 2016 at 2:51 PM, 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.

Re: Openstack HA Portland Meetup Present

On 18/03/16 05:41, James Beedy wrote: > I just gave this presentation --> http://54.172.233.114/ at an Openstack > meetup at puppet headquarters in Portland, geared around HA Openstack > production deployments. I wanted to update the team of the great news! It > was by far the best presentation I