Re: Juju terminology change: controllers and models

[John Meinel]

What did we end up doing for Login? I'm thinking it would be good to keep a
v1 login around that would tell <=1.25 clients that they need a different
version of their client to talk to this server.

John
=:->
On Feb 3, 2016 9:03 PM, "Eric Snow"  wrote:

> Thanks for this in-depth break-down, Ian.  It really helps.
>
> -eric
>
> On Tue, Feb 2, 2016 at 6:33 PM, Ian Booth  wrote:
> > Hey all
> >
> > As has been mentioned previously in this list, for the Juju 2.0 release
> we have
> > been working on fundamental terminology changes. In particular, we now
> talk
> > about controllers and models instead of state servers and environments.
> >
> > To this end, a rather large change has landed in master and the upcoming
> > 2.0-alpha2 release of Juju will reflect these changes. There are several
> things
> > to be aware of. We have also taken the opportunity to remove a lot of
> code which
> > existed to support older Juju clients. Needless to say, this Juju 2.0
> release
> > will not support upgrading from 1.x - it works only as a clean install.
> >
> > Note: some of the changes will initially break the GUI and users of the
> Python
> > Juju Client - work is underway to update these products for the next
> alpha3
> > release scheduled for next week. For those wishing to continue to test
> Juju 2.0
> > without the breaking changes, the alpha1 release is still available via
> > ppa:juju/experimental. Separate communications to affected stakeholders
> has/will
> > be made as part of the 2.0-alpha2 release.
> >
> > So, the changes are roughly broken down as follows:
> >
> > - CLI command name changes
> > - facade name changes
> > - api method and parameter name changes
> > - facade method restructure
> > - internal api name changes
> > - external artifact/data changes (including on the wire changes)
> > - deprecated and older version facades are removed
> >
> > 1. CLI command name changes
> >
> > As an obvious example, create-environment becomes create-model. We also
> have
> > destroy-controller etc. This alpha2 release will also contain many of
> the other
> > CLI changes targetted for 2.0 eg juju backup create becomes juju
> create-backup.
> > Not all 2.0 CLI syntax is supported yet, but all the environment -> model
> > changes are done.
> >
> > You will also use -m  instead of -e .
> >
> > The release notes will go into more detail.
> >
> > All user facing text now refers to model instead of environment.
> >
> > 2. Facade name changes
> >
> > If you are curious, see https://goo.gl/l4JqGd for a representative
> listing of
> > all facade and method names and which ones have been changed.
> >
> > The main one is EnvironmentManager becomes ModelManager. These changes
> affect
> > external API clients like the GUI and Python Juju client.
> >
> > 3. api method and parameter name changes
> >
> > By way of example:
> > EnvironInfo() on the undertaker facade becomes ModelInfo().
> > The param struct ModifyEnvironUsers becomes ModifyModelUsers etc.
> > EnvironTag attributes become ModelTag.
> >
> > 4. Service facade method restructure
> >
> > As part of making our facades more manageable and maintainable when API
> changes
> > are required, a whole bunch of service related methods are moved off the
> Client
> > facade and onto the Service facade. This had already been started months
> ago,
> > and there were shims in place to keep existing clients working, but now
> the job
> > is finished.
> > eg Client.AddRelation() becomes Service.AddRelation() etc.
> >
> > This change will break the GUI and Python Juju client.
> >
> > 5. Internal API name changes
> >
> > Things like state.AllEnvironments() becomes state.AllModels(), we now use
> > names.ModelTag instead of names.EnvironTag, and many, many more.
> >
> > Note: the names package has not been forked into a .V2 yet (with
> EnvironTag
> > removed) as there are dependencies to sort out. Please do not use
> EnvironTag
> > anymore.
> >
> > 6. External artifact/data changes (including on the wire changes)
> >
> > There are several main examples here.
> > On the wire, we transmit model-uuid tags rather than environment-uuid
> tags.
> > In mongo, we store model-uuid doc fields rather than env-uuid.
> > In agent.conf files we store Model info rather than Environment tags.
> > In the controller blob store, we store and manage blobs for buckets
> rather than
> > environments.
> > The controller HTTP endpoints are /model/ > In backups we store model tags and details, not environment.
> >
> > With the blobstore, we've create a .V2 branch which core uses. The
> charmstore
> > will continue to use V1 for now.
> >
> > 7. Deprecated and older version facades are removed
> >
> > All facade versions have been bumped up. Older facades are removed, and
> we don't
> > support fallback to older servers. The main example for facade removal
> is uniter
> > v0 and v1 are gone. With deprecated API removal, service deployment now
> expects
> > 

Juju terminology change: controllers and models

[Ian Booth]

Hey all

As has been mentioned previously in this list, for the Juju 2.0 release we have
been working on fundamental terminology changes. In particular, we now talk
about controllers and models instead of state servers and environments.

To this end, a rather large change has landed in master and the upcoming
2.0-alpha2 release of Juju will reflect these changes. There are several things
to be aware of. We have also taken the opportunity to remove a lot of code which
existed to support older Juju clients. Needless to say, this Juju 2.0 release
will not support upgrading from 1.x - it works only as a clean install.

Note: some of the changes will initially break the GUI and users of the Python
Juju Client - work is underway to update these products for the next alpha3
release scheduled for next week. For those wishing to continue to test Juju 2.0
without the breaking changes, the alpha1 release is still available via
ppa:juju/experimental. Separate communications to affected stakeholders has/will
be made as part of the 2.0-alpha2 release.

So, the changes are roughly broken down as follows:

- CLI command name changes
- facade name changes
- api method and parameter name changes
- facade method restructure
- internal api name changes
- external artifact/data changes (including on the wire changes)
- deprecated and older version facades are removed

1. CLI command name changes

As an obvious example, create-environment becomes create-model. We also have
destroy-controller etc. This alpha2 release will also contain many of the other
CLI changes targetted for 2.0 eg juju backup create becomes juju create-backup.
Not all 2.0 CLI syntax is supported yet, but all the environment -> model
changes are done.

You will also use -m  instead of -e .

The release notes will go into more detail.

All user facing text now refers to model instead of environment.

2. Facade name changes

If you are curious, see https://goo.gl/l4JqGd for a representative listing of
all facade and method names and which ones have been changed.

The main one is EnvironmentManager becomes ModelManager. These changes affect
external API clients like the GUI and Python Juju client.

3. api method and parameter name changes

By way of example:
EnvironInfo() on the undertaker facade becomes ModelInfo().
The param struct ModifyEnvironUsers becomes ModifyModelUsers etc.
EnvironTag attributes become ModelTag.

4. Service facade method restructure

As part of making our facades more manageable and maintainable when API changes
are required, a whole bunch of service related methods are moved off the Client
facade and onto the Service facade. This had already been started months ago,
and there were shims in place to keep existing clients working, but now the job
is finished.
eg Client.AddRelation() becomes Service.AddRelation() etc.

This change will break the GUI and Python Juju client.

5. Internal API name changes

Things like state.AllEnvironments() becomes state.AllModels(), we now use
names.ModelTag instead of names.EnvironTag, and many, many more.

Note: the names package has not been forked into a .V2 yet (with EnvironTag
removed) as there are dependencies to sort out. Please do not use EnvironTag
anymore.

6. External artifact/data changes (including on the wire changes)

There are several main examples here.
On the wire, we transmit model-uuid tags rather than environment-uuid tags.
In mongo, we store model-uuid doc fields rather than env-uuid.
In agent.conf files we store Model info rather than Environment tags.
In the controller blob store, we store and manage blobs for buckets rather than
environments.
The controller HTTP endpoints are /model/https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju terminology change: controllers and models

[Ian Booth]

Yeah, there's a couple of places that need a bit of cleanup. With that one, I
needed to double check existing call points before deleting, and ran out of time
before needing to do the merge. But the intent is to delete it.

On 03/02/16 12:53, Nate Finch wrote:
> FYI, I noticed ServiceDeployWithNetworks still exists as a client and
> facade method, but it's only called by tests. Maybe it should be removed?
> 
> On Tue, Feb 2, 2016, 8:34 PM Ian Booth  wrote:
> 
>> Hey all
>>
>> As has been mentioned previously in this list, for the Juju 2.0 release we
>> have
>> been working on fundamental terminology changes. In particular, we now talk
>> about controllers and models instead of state servers and environments.
>>
>> To this end, a rather large change has landed in master and the upcoming
>> 2.0-alpha2 release of Juju will reflect these changes. There are several
>> things
>> to be aware of. We have also taken the opportunity to remove a lot of code
>> which
>> existed to support older Juju clients. Needless to say, this Juju 2.0
>> release
>> will not support upgrading from 1.x - it works only as a clean install.
>>
>> Note: some of the changes will initially break the GUI and users of the
>> Python
>> Juju Client - work is underway to update these products for the next alpha3
>> release scheduled for next week. For those wishing to continue to test
>> Juju 2.0
>> without the breaking changes, the alpha1 release is still available via
>> ppa:juju/experimental. Separate communications to affected stakeholders
>> has/will
>> be made as part of the 2.0-alpha2 release.
>>
>> So, the changes are roughly broken down as follows:
>>
>> - CLI command name changes
>> - facade name changes
>> - api method and parameter name changes
>> - facade method restructure
>> - internal api name changes
>> - external artifact/data changes (including on the wire changes)
>> - deprecated and older version facades are removed
>>
>> 1. CLI command name changes
>>
>> As an obvious example, create-environment becomes create-model. We also
>> have
>> destroy-controller etc. This alpha2 release will also contain many of the
>> other
>> CLI changes targetted for 2.0 eg juju backup create becomes juju
>> create-backup.
>> Not all 2.0 CLI syntax is supported yet, but all the environment -> model
>> changes are done.
>>
>> You will also use -m  instead of -e .
>>
>> The release notes will go into more detail.
>>
>> All user facing text now refers to model instead of environment.
>>
>> 2. Facade name changes
>>
>> If you are curious, see https://goo.gl/l4JqGd for a representative
>> listing of
>> all facade and method names and which ones have been changed.
>>
>> The main one is EnvironmentManager becomes ModelManager. These changes
>> affect
>> external API clients like the GUI and Python Juju client.
>>
>> 3. api method and parameter name changes
>>
>> By way of example:
>> EnvironInfo() on the undertaker facade becomes ModelInfo().
>> The param struct ModifyEnvironUsers becomes ModifyModelUsers etc.
>> EnvironTag attributes become ModelTag.
>>
>> 4. Service facade method restructure
>>
>> As part of making our facades more manageable and maintainable when API
>> changes
>> are required, a whole bunch of service related methods are moved off the
>> Client
>> facade and onto the Service facade. This had already been started months
>> ago,
>> and there were shims in place to keep existing clients working, but now
>> the job
>> is finished.
>> eg Client.AddRelation() becomes Service.AddRelation() etc.
>>
>> This change will break the GUI and Python Juju client.
>>
>> 5. Internal API name changes
>>
>> Things like state.AllEnvironments() becomes state.AllModels(), we now use
>> names.ModelTag instead of names.EnvironTag, and many, many more.
>>
>> Note: the names package has not been forked into a .V2 yet (with EnvironTag
>> removed) as there are dependencies to sort out. Please do not use
>> EnvironTag
>> anymore.
>>
>> 6. External artifact/data changes (including on the wire changes)
>>
>> There are several main examples here.
>> On the wire, we transmit model-uuid tags rather than environment-uuid tags.
>> In mongo, we store model-uuid doc fields rather than env-uuid.
>> In agent.conf files we store Model info rather than Environment tags.
>> In the controller blob store, we store and manage blobs for buckets rather
>> than
>> environments.
>> The controller HTTP endpoints are /model/> In backups we store model tags and details, not environment.
>>
>> With the blobstore, we've create a .V2 branch which core uses. The
>> charmstore
>> will continue to use V1 for now.
>>
>> 7. Deprecated and older version facades are removed
>>
>> All facade versions have been bumped up. Older facades are removed, and we
>> don't
>> support fallback to older servers. The main example for facade removal is
>> uniter
>> v0 and v1 are gone. With deprecated API removal, service deployment now
>> expects
>> placement parameters rather than 

Re: Juju terminology change: controllers and models

[Marco Ceppi]

Very exciting to see these bits landing now! I'm looking forward to the
alpha and trying out all the commands

On Wed, Feb 3, 2016 at 12:05 AM Ian Booth  wrote:

> Yeah, there's a couple of places that need a bit of cleanup. With that
> one, I
> needed to double check existing call points before deleting, and ran out
> of time
> before needing to do the merge. But the intent is to delete it.
>
> On 03/02/16 12:53, Nate Finch wrote:
> > FYI, I noticed ServiceDeployWithNetworks still exists as a client and
> > facade method, but it's only called by tests. Maybe it should be removed?
> >
> > On Tue, Feb 2, 2016, 8:34 PM Ian Booth  wrote:
> >
> >> Hey all
> >>
> >> As has been mentioned previously in this list, for the Juju 2.0 release
> we
> >> have
> >> been working on fundamental terminology changes. In particular, we now
> talk
> >> about controllers and models instead of state servers and environments.
> >>
> >> To this end, a rather large change has landed in master and the upcoming
> >> 2.0-alpha2 release of Juju will reflect these changes. There are several
> >> things
> >> to be aware of. We have also taken the opportunity to remove a lot of
> code
> >> which
> >> existed to support older Juju clients. Needless to say, this Juju 2.0
> >> release
> >> will not support upgrading from 1.x - it works only as a clean install.
> >>
> >> Note: some of the changes will initially break the GUI and users of the
> >> Python
> >> Juju Client - work is underway to update these products for the next
> alpha3
> >> release scheduled for next week. For those wishing to continue to test
> >> Juju 2.0
> >> without the breaking changes, the alpha1 release is still available via
> >> ppa:juju/experimental. Separate communications to affected stakeholders
> >> has/will
> >> be made as part of the 2.0-alpha2 release.
> >>
> >> So, the changes are roughly broken down as follows:
> >>
> >> - CLI command name changes
> >> - facade name changes
> >> - api method and parameter name changes
> >> - facade method restructure
> >> - internal api name changes
> >> - external artifact/data changes (including on the wire changes)
> >> - deprecated and older version facades are removed
> >>
> >> 1. CLI command name changes
> >>
> >> As an obvious example, create-environment becomes create-model. We also
> >> have
> >> destroy-controller etc. This alpha2 release will also contain many of
> the
> >> other
> >> CLI changes targetted for 2.0 eg juju backup create becomes juju
> >> create-backup.
> >> Not all 2.0 CLI syntax is supported yet, but all the environment ->
> model
> >> changes are done.
> >>
> >> You will also use -m  instead of -e .
> >>
> >> The release notes will go into more detail.
> >>
> >> All user facing text now refers to model instead of environment.
> >>
> >> 2. Facade name changes
> >>
> >> If you are curious, see https://goo.gl/l4JqGd for a representative
> >> listing of
> >> all facade and method names and which ones have been changed.
> >>
> >> The main one is EnvironmentManager becomes ModelManager. These changes
> >> affect
> >> external API clients like the GUI and Python Juju client.
> >>
> >> 3. api method and parameter name changes
> >>
> >> By way of example:
> >> EnvironInfo() on the undertaker facade becomes ModelInfo().
> >> The param struct ModifyEnvironUsers becomes ModifyModelUsers etc.
> >> EnvironTag attributes become ModelTag.
> >>
> >> 4. Service facade method restructure
> >>
> >> As part of making our facades more manageable and maintainable when API
> >> changes
> >> are required, a whole bunch of service related methods are moved off the
> >> Client
> >> facade and onto the Service facade. This had already been started months
> >> ago,
> >> and there were shims in place to keep existing clients working, but now
> >> the job
> >> is finished.
> >> eg Client.AddRelation() becomes Service.AddRelation() etc.
> >>
> >> This change will break the GUI and Python Juju client.
> >>
> >> 5. Internal API name changes
> >>
> >> Things like state.AllEnvironments() becomes state.AllModels(), we now
> use
> >> names.ModelTag instead of names.EnvironTag, and many, many more.
> >>
> >> Note: the names package has not been forked into a .V2 yet (with
> EnvironTag
> >> removed) as there are dependencies to sort out. Please do not use
> >> EnvironTag
> >> anymore.
> >>
> >> 6. External artifact/data changes (including on the wire changes)
> >>
> >> There are several main examples here.
> >> On the wire, we transmit model-uuid tags rather than environment-uuid
> tags.
> >> In mongo, we store model-uuid doc fields rather than env-uuid.
> >> In agent.conf files we store Model info rather than Environment tags.
> >> In the controller blob store, we store and manage blobs for buckets
> rather
> >> than
> >> environments.
> >> The controller HTTP endpoints are /model/ >> In backups we store model tags and details, not environment.
> >>
> >> With the blobstore, we've 

Re: Juju terminology change: controllers and models

[Nate Finch]

FYI, I noticed ServiceDeployWithNetworks still exists as a client and
facade method, but it's only called by tests. Maybe it should be removed?

On Tue, Feb 2, 2016, 8:34 PM Ian Booth  wrote:

> Hey all
>
> As has been mentioned previously in this list, for the Juju 2.0 release we
> have
> been working on fundamental terminology changes. In particular, we now talk
> about controllers and models instead of state servers and environments.
>
> To this end, a rather large change has landed in master and the upcoming
> 2.0-alpha2 release of Juju will reflect these changes. There are several
> things
> to be aware of. We have also taken the opportunity to remove a lot of code
> which
> existed to support older Juju clients. Needless to say, this Juju 2.0
> release
> will not support upgrading from 1.x - it works only as a clean install.
>
> Note: some of the changes will initially break the GUI and users of the
> Python
> Juju Client - work is underway to update these products for the next alpha3
> release scheduled for next week. For those wishing to continue to test
> Juju 2.0
> without the breaking changes, the alpha1 release is still available via
> ppa:juju/experimental. Separate communications to affected stakeholders
> has/will
> be made as part of the 2.0-alpha2 release.
>
> So, the changes are roughly broken down as follows:
>
> - CLI command name changes
> - facade name changes
> - api method and parameter name changes
> - facade method restructure
> - internal api name changes
> - external artifact/data changes (including on the wire changes)
> - deprecated and older version facades are removed
>
> 1. CLI command name changes
>
> As an obvious example, create-environment becomes create-model. We also
> have
> destroy-controller etc. This alpha2 release will also contain many of the
> other
> CLI changes targetted for 2.0 eg juju backup create becomes juju
> create-backup.
> Not all 2.0 CLI syntax is supported yet, but all the environment -> model
> changes are done.
>
> You will also use -m  instead of -e .
>
> The release notes will go into more detail.
>
> All user facing text now refers to model instead of environment.
>
> 2. Facade name changes
>
> If you are curious, see https://goo.gl/l4JqGd for a representative
> listing of
> all facade and method names and which ones have been changed.
>
> The main one is EnvironmentManager becomes ModelManager. These changes
> affect
> external API clients like the GUI and Python Juju client.
>
> 3. api method and parameter name changes
>
> By way of example:
> EnvironInfo() on the undertaker facade becomes ModelInfo().
> The param struct ModifyEnvironUsers becomes ModifyModelUsers etc.
> EnvironTag attributes become ModelTag.
>
> 4. Service facade method restructure
>
> As part of making our facades more manageable and maintainable when API
> changes
> are required, a whole bunch of service related methods are moved off the
> Client
> facade and onto the Service facade. This had already been started months
> ago,
> and there were shims in place to keep existing clients working, but now
> the job
> is finished.
> eg Client.AddRelation() becomes Service.AddRelation() etc.
>
> This change will break the GUI and Python Juju client.
>
> 5. Internal API name changes
>
> Things like state.AllEnvironments() becomes state.AllModels(), we now use
> names.ModelTag instead of names.EnvironTag, and many, many more.
>
> Note: the names package has not been forked into a .V2 yet (with EnvironTag
> removed) as there are dependencies to sort out. Please do not use
> EnvironTag
> anymore.
>
> 6. External artifact/data changes (including on the wire changes)
>
> There are several main examples here.
> On the wire, we transmit model-uuid tags rather than environment-uuid tags.
> In mongo, we store model-uuid doc fields rather than env-uuid.
> In agent.conf files we store Model info rather than Environment tags.
> In the controller blob store, we store and manage blobs for buckets rather
> than
> environments.
> The controller HTTP endpoints are /model/ In backups we store model tags and details, not environment.
>
> With the blobstore, we've create a .V2 branch which core uses. The
> charmstore
> will continue to use V1 for now.
>
> 7. Deprecated and older version facades are removed
>
> All facade versions have been bumped up. Older facades are removed, and we
> don't
> support fallback to older servers. The main example for facade removal is
> uniter
> v0 and v1 are gone. With deprecated API removal, service deployment now
> expects
> placement parameters rather than catering for older clients that did not
> support
> placement, so there's only one ServiceDeployMethod() instead of 3. All in
> all,
> the code base has been simplified by removing all support for deprecated
> facades
> and API calls.
>
> There are still a couple of grey areas internally to be sorted out. But
> the user
> facing changes are done (pending more CLI work between now and