Re: Juju 2.0-beta9 ETA

Thanks Tim and I want to say that I really appreciate this change. The way the API exposed the Go-ism that all exported attributes are capitalized has been annoying for some time. I really appreciate you cleaning that up for users of the API. I think the only thing I'd change on this is that we

Re: Juju 2.0-beta9 ETA

Hi folks, Due to a change I landed without fully thinking through the implications, the reverting of said change has pushed us out a day. I was trying to add consistency to the wire-protocol that Juju uses by changing the serialisation names. Thinking that we were still in the "we don't

Re: Juju 2.0-beta9 ETA

Hi Everyone, Due to a critical bug [0] found in the daily PPA, the release of 2.0-beta9 will be delayed while we test the fix. We are aiming for a release tomorrow. Thanks! -Cheryl [0] https://bugs.launchpad.net/juju-core/+bug/1592210 On Fri, Jun 10, 2016 at 1:20 PM, Cheryl Jennings <

Re: Juju 2.0-beta9 ETA

On 2016-06-13 09:35 AM, Ian Booth wrote: > $ juju set-model-config foo=bar > > That sets foo on the current model. Or > > $ juju -m mymodel set-model-config foo=bar > > operates on model mymodel. > > The above are model commands. So we need a way to set foo=bar on the > controller > itself

Re: Juju 2.0-beta9 ETA

For JAAS, doesn't a 'default model property' need to be a user level setting, because it doesn't make sense as at a Controller level because all-of-JAAS is your Controller (we don't expose the individual controllers). We should also consider how Migration is impacted by defaults like this. John

Re: Juju 2.0-beta9 ETA

On 14/06/16 08:33, Ian Booth wrote: >> That's why I prefer: >> >> set-controller-config >> set-model-config >> set-model-default >> > I like the above too. But some folks we've talked to have thought that > introducing 3 commands (the ones above) is cognitive overhead. Heh. Ian, if you like,

Re: Juju 2.0-beta9 ETA

On 13/06/16 13:56, Rick Harding wrote: > I've felt like the least oddball of things was to tie the command to > remove the entry to the command you used to add it and so we've been > running with unregister. +1 At one stage we were using login with different parameters instead of register; I'm

Re: Juju 2.0-beta9 ETA

On 13/06/16 22:58, Rick Harding wrote: > On Sat, Jun 11, 2016 at 6:32 PM Ian Booth wrote: > >> We are also storing any config specified in clouds.yaml separately. These >> items, >> such as apt-mirror, are shared between models and are used by default if >> not >>

Re: Juju 2.0-beta9 ETA

On Sat, Jun 11, 2016 at 6:32 PM Ian Booth wrote: > We are also storing any config specified in clouds.yaml separately. These > items, > such as apt-mirror, are shared between models and are used by default if > not > specified in a hosted model. But you can override any

Re: Juju 2.0-beta9 ETA

On Sat, Jun 11, 2016 at 11:33 AM Mark Shuttleworth wrote: > On 10/06/16 19:20, Cheryl Jennings wrote: > > - Addition of a `juju unregister` command to remove references to > > controllers > > Seems we have two different cases > > * the opposite of register > * the opposite of

Re: Juju 2.0-beta9 ETA

On 12/06/16 21:00, Mark Shuttleworth wrote: From an upgrade point of view, I would focus on the migration capability, because that provides the cleanest semantics. If we have everything we need there and upgrades happen to work from b9 onwards, then that's great, but please communicate that I

Re: Juju 2.0-beta9 ETA

On the upgrade front, I think we should relax until we are comfortable calling something an RC. The reality is we are still making changes, I am concerned that making an upgrade promise too early will just slow down our ability to make changes we deem necessary before 2.0. I understand there are

Re: Juju 2.0-beta9 ETA

On 12/06/16 02:30, Dean Henrichsmeyer wrote: > On Fri, Jun 10, 2016 at 1:20 PM, Cheryl Jennings < > cheryl.jenni...@canonical.com> wrote: > > >> Some of the great things coming in beta9 include: >> - Separation of controller config vs. model config >> > > Will this one have user-facing