Re: Backwards incompatible change to config.changed states

2016-04-22 Thread Merlijn Sebrechts
Hi Cory I think this is another symptom of the deeper issue that the reactive framework treats events like states. 'config.changed' is an event. The following code is something that intuitively seems correct. We want to reinstall when the config has changed while the service is installed.

Re: Backwards incompatible change to config.changed states

2016-04-22 Thread Cory Johns
We can skip the new state if no one is depending on or finds the existing behavior useful (I suspect that may be true). On Fri, Apr 22, 2016 at 5:37 PM, Mark Shuttleworth wrote: > > I would strongly prefer not to add states lightly. Can we take some time > to see if this is

Re: Backwards incompatible change to config.changed states

2016-04-22 Thread Mark Shuttleworth
I would strongly prefer not to add states lightly. Can we take some time to see if this is avoidable? Mark On 22/04/16 16:02, Cory Johns wrote: > I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a > slight change to how the config.changed states from the basic layer

Backwards incompatible change to config.changed states

2016-04-22 Thread Cory Johns
I have proposed https://github.com/juju-solutions/layer-basic/pull/61 as a slight change to how the config.changed states from the basic layer work. Currently, the changed states are set during the first hook invocation, under the assumption that the values were "changed" from "nothing" (not being

auto-upgrading models

2016-04-22 Thread Eric Snow
In a recent bug I was working on the issue of auto-upgrading models came up. I also ran into this personally not too long ago. Currently, running "juju upgrade-juju -m admin --upload-tools"[1] upgrades the admin model to a new version. To set the version of any other model to the uploaded one,

two new helpers in github.com/juju/testing

2016-04-22 Thread Nate Finch
I added a couple new helpers to the testing repo that I think will help us avoid some of the contortions we have had to do in the past when testing executables and output on stderr/stdout. The first is a fairly simple function, CaptureOutput

Re: Juju Office Hours, release week edition, this Thursday, 21 April.

2016-04-22 Thread Jorge O. Castro
And here's the video, thanks to everyone for all the questions in IRC and the hangout: https://www.youtube.com/watch?v=F_1o517ibTo On Mon, Apr 18, 2016 at 9:46 AM, Jorge O. Castro wrote: > It's time for another Juju Office Hours! It's release week so we've > decided to do a

a few notes on common windows breaking mistakes.

2016-04-22 Thread Horacio Duran
Hello all, this past week I have spent some time fixing Wintows tests for go 1.6, many errors where caused by http being more strict on what it will take on a Get and therefore many innocent mistakes often made in tests where suddenly not so innocent, so just as a friendly reminder. * Always join

Re: 16.04 OpenStack charm release

2016-04-22 Thread Adam Collard
Well done everyone! Looking forward to playing with all the new bits :) On Fri, 22 Apr 2016 at 10:02 Liam Young wrote: > Hi All > > We are pleased to announce the 16.04 release of the OpenStack charms. > Highlights include: > > * Full Ubuntu 16.04 support > *

Re: 16.04 OpenStack charm release

2016-04-22 Thread ed bond
Liam, Great news! Is there a bundle that shows these uses yet? - Firl > On Apr 22, 2016, at 4:01 AM, Liam Young wrote: > > Hi All > > We are pleased to announce the 16.04 release of the OpenStack charms. > Highlights include: > * Full Ubuntu 16.04 support > *

16.04 OpenStack charm release

2016-04-22 Thread Liam Young
Hi All We are pleased to announce the 16.04 release of the OpenStack charms. Highlights include: * Full Ubuntu 16.04 support * OpenStack Mitaka Support on 14.04 and 16.04 * Ceph MON charm * Cinder Backup charm * Nova/Neutron separation * Pause/Resume actions * Internal API endpoint usages