Re: Juju 2.0-beta9 ETA

[Rick Harding]

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 notify users that it's
going on with an email to the public Juju list. We've got the patch and
let's definitely consider this heads up to everyone in the ecosystem that
the change is coming and look for this in a daily build coming to you very
soon.

On Wed, Jun 15, 2016 at 4:36 PM Tim Penhey  wrote:

> 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 need no backward compatibility phase" I made this change without
> bumping the facade versions. This would have broken all the API users.
> This is what we are backing out.
>
> Sorry for the inconvenience.
>
> Tim
>
> On 15/06/16 12:19, Cheryl Jennings wrote:
> > 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
> > >
> > wrote:
> >
> > The team has been busily working on 2.0-beta9 with an aim to address
> > usability feedback and ensure that beta9 will be upgradeable to
> > subsequent releases.  Ensuring upgradeability has required a
> > significant amount of work to finalize internal details, and the
> > team needs a few extra days to make sure this work is completed.
> >
> > To achieve this guarantee, we are moving the expected date for
> > 2.0-beta9 to Tuesday, June 14.
> >
> > Some of the great things coming in beta9 include:
> > - Renaming of 'service' to 'application' to better align terminology
> > - Shortened instance IDs for the lxd provider (ex: 'juju-622af3-0')
> > - Addition of a `juju unregister` command to remove references to
> > controllers
> > - Separation of controller config vs. model config
> > - Improved status output
> > - Numerous bug fixes
> >
> > There is an early beta9 available in the juju daily ppa
> > (ppa:juju/daily) for those who wish early access to the above
> features.
> >
> > If you have any questions, please let me know.
> > Thanks!
> > -Cheryl
> >
> >
> >
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
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-beta9 ETA

[Tim Penhey]

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 need no backward compatibility phase" I made this change without 
bumping the facade versions. This would have broken all the API users. 
This is what we are backing out.


Sorry for the inconvenience.

Tim

On 15/06/16 12:19, Cheryl Jennings wrote:

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
>
wrote:

The team has been busily working on 2.0-beta9 with an aim to address
usability feedback and ensure that beta9 will be upgradeable to
subsequent releases.  Ensuring upgradeability has required a
significant amount of work to finalize internal details, and the
team needs a few extra days to make sure this work is completed.

To achieve this guarantee, we are moving the expected date for
2.0-beta9 to Tuesday, June 14.

Some of the great things coming in beta9 include:
- Renaming of 'service' to 'application' to better align terminology
- Shortened instance IDs for the lxd provider (ex: 'juju-622af3-0')
- Addition of a `juju unregister` command to remove references to
controllers
- Separation of controller config vs. model config
- Improved status output
- Numerous bug fixes

There is an early beta9 available in the juju daily ppa
(ppa:juju/daily) for those who wish early access to the above features.

If you have any questions, please let me know.
Thanks!
-Cheryl






--
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-beta9 ETA

[Cheryl Jennings]

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 <
cheryl.jenni...@canonical.com> wrote:

> The team has been busily working on 2.0-beta9 with an aim to address
> usability feedback and ensure that beta9 will be upgradeable to subsequent
> releases.  Ensuring upgradeability has required a significant amount of
> work to finalize internal details, and the team needs a few extra days to
> make sure this work is completed.
>
> To achieve this guarantee, we are moving the expected date for 2.0-beta9
> to Tuesday, June 14.
>
> Some of the great things coming in beta9 include:
> - Renaming of 'service' to 'application' to better align terminology
> - Shortened instance IDs for the lxd provider (ex: 'juju-622af3-0')
> - Addition of a `juju unregister` command to remove references to
> controllers
> - Separation of controller config vs. model config
> - Improved status output
> - Numerous bug fixes
>
> There is an early beta9 available in the juju daily ppa (ppa:juju/daily)
> for those who wish early access to the above features.
>
> If you have any questions, please let me know.
> Thanks!
> -Cheryl
>
-- 
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-beta9 ETA

[Aaron Bentley]

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 (ie update the shared controller wide config). What are you proposing?
> Did you intend that setting foo on the controller model would satisfy the
> requirement?

Maybe a flag on set-model-config would be the way to go.  It would
conflict with -m.

e.g.

$ juju set-model-config --controller-default foo=bar.

(The name could probably be improved.)

Aaron



signature.asc
Description: OpenPGP digital signature
-- 
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-beta9 ETA

[John Meinel]

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
=:->


On Tue, Jun 14, 2016 at 11:54 AM, Mark Shuttleworth  wrote:

> 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, and I like it, let's just do it :)
>
> What will we do for JAAS, where there will be many controller and many
> clouds? Seems like we should make sure that any cloud-specific defaults
> / properties are not inadvertently implemented as model config/defaults.
>
> Mark
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
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-beta9 ETA

[Mark Shuttleworth]

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, and I like it, let's just do it :)

What will we do for JAAS, where there will be many controller and many
clouds? Seems like we should make sure that any cloud-specific defaults
/ properties are not inadvertently implemented as model config/defaults.

Mark


-- 
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-beta9 ETA

[Mark Shuttleworth]

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 comfortable with register/unregister in this case where it
is "not your controller".

Mark

-- 
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-beta9 ETA

[Ian Booth]

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
>> specified in a hosted model. But you can override any such items as well
>> simply
>> by setting them on the model. For now, the semantics of this change are
>> transparent - get-model-config will show the accumulation of shared and
>> model
>> specific settings. But we are looking to add a command to show/set shared
>> config. Thus you will be able to say update a http-proxy setting across all
>> hosted models within a controller with one command:
>>
>> juju set-shared-config http-proxy=foo
>>
>> NB command name to be decided.
>>
> 
> Ian, can we setup some time to chat on this. I'm curious if, rather than a
> command to explicitly "set everywhere" we follow the model that the config
> is inherited unless overridden for a specific model. Then by setting it on

What you say above is how it will work. You bootstrap a controller and any
config specified in clouds.yaml for that cloud becomes the default inherited
config for all hosted models add to the controller. But you can then choose to
set a config value on your hosted model, and that will override anything that
was being used as the default.

> the controller all models would get it. If you want it set on a specific
> model, you'd set it on the model. In that way there'd not be a third/new
> command for setting config.
> 

"Setting it on the controller" - that's what we are proposing. Once you have
bootstrapped the controller and the shared default config for hosted models has
been set up (by virtue of the settings in clouds.yaml), you then need a way to
alter that shared config. Is that what you mean? What command would you like for
that? We have

$ 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 (ie update the shared controller wide config). What are you proposing?
Did you intend that setting foo on the controller model would satisfy the
requirement? That seems to be wrong for 2 reasons:

1. It's a model not a controller
2. The controller model can be used to host applications (eg nagios), and as
such the controller model settings may we be required to be set in and of
themselves, and to conflate those with default controller side config seems 
wrong.

Maybe I'm thinking wrongly, but I make a very clear distinction in my mind
between the controller and its models. There should be separate commands for
managing controller artifacts, including  ACLs, vs model artifacts.

Speaking of ACLs, the same distinction applies. You want to manage access to the
controller - who can create models, who can share models, who can delete models
not their own, who can register users etc - vs model level operations - who can
deploy applications etc. And so again, the controller model permissions are
different semantically to the controller permissions. You can manage who can
create applications in the controller model, which is different to an operation
on the controller itself like registering a user. You may grant fred access to
the controller model, but not the controller itself.

Or maybe I'm misunderstanding what you mean?






-- 
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-beta9 ETA

[Rick Harding]

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 such items as well
> simply
> by setting them on the model. For now, the semantics of this change are
> transparent - get-model-config will show the accumulation of shared and
> model
> specific settings. But we are looking to add a command to show/set shared
> config. Thus you will be able to say update a http-proxy setting across all
> hosted models within a controller with one command:
>
> juju set-shared-config http-proxy=foo
>
> NB command name to be decided.
>

Ian, can we setup some time to chat on this. I'm curious if, rather than a
command to explicitly "set everywhere" we follow the model that the config
is inherited unless overridden for a specific model. Then by setting it on
the controller all models would get it. If you want it set on a specific
model, you'd set it on the model. In that way there'd not be a third/new
command for setting 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-beta9 ETA

[Rick Harding]

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 bootstrap
>
> Why not just remove-controller and remove-account ?
>

The opposite of bootstrap we stuck with destroy as we kept destroy and
remove in the vocabulary because it was helpful to keep "not coming back"
like destroy-service and destroy-controller. I think with the safe guards
in place around destroy-controller I'm +1 with just moving to remove across
the board. It simplifies the language if we're ok with not keeping the
destroy vs remove semantics.

The opposite of register is harder. You're looking to remove an entry of
something you see in list-controllers. You put it there by registering and
giving it a name in that process. We don't have the noun/idea of "account"
in Juju at the moment. You add a User, which lead that user to registering
that controller. It lead us through share/unshare, register/unregister,
etc. It's not a remove/destroy controller as that's limited in who can do
that and is not something you want to accidentally do if you typo the wrong
entry in list-controllers.  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.
-- 
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-beta9 ETA

[Tim Penhey]

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 will not hesitate to
make breaking changes until we are in RC if that's the right thing to do
for 2.0. I'll call the RC when I think the experience is crisp - we have
made huge strides in the pat weeks in that regard, let's not slow down now.


Unfortunately, migrations is a piece of work that isn't yet ready. We 
are working on it, but it won't be ready for a number of weeks yet.


Tim

--
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-beta9 ETA

[Mark Shuttleworth]

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 some large deployments for which 2.0 (or even a
beta that is upgradeable) would be a significant boon, but I think we
will benefit from agility in the coming weeks if we can focus on doing
what's right for the experience without having to wriggle around
upgrades. Our priority is to make a great impression on all the new
people that will check out the 2.0 release, so let's focus on that. When
we are ready we will call it an RC and make the upgradeability promise.

>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 will not hesitate to
make breaking changes until we are in RC if that's the right thing to do
for 2.0. I'll call the RC when I think the experience is crisp - we have
made huge strides in the pat weeks in that regard, let's not slow down now.

Mark


-- 
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-beta9 ETA

[Ian Booth]

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 changes or is it internal?
> 

The separation of controller config is internal. Controller config includes:
- ca cert
- api port
- mongo port

These items are not used by Juju models at all but currently show up when you do
a juju get-model-config. In beta 10, this will not be the case. So from that
aspect, it's user facing but it means get-model-config will be a lot more user
friendly since you won't have a wall of text for a cert you don't care about.
There will be a separate get-controller-config command to see those items. They
are typically immutable.

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 such items as well simply
by setting them on the model. For now, the semantics of this change are
transparent - get-model-config will show the accumulation of shared and model
specific settings. But we are looking to add a command to show/set shared
config. Thus you will be able to say update a http-proxy setting across all
hosted models within a controller with one command:

juju set-shared-config http-proxy=foo

NB command name to be decided.

The other change for beta 10 will be to no longer store in model config
transient settings like bootstrap timeout which are not relevant once a
controller is running. This will also remove clutter from model settings.




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