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 <ian.booth at canonical.com> 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 <model> instead of -e <environment>.
>>
>> 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/<model-uuid/...
>> 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 release).
>>
>>
>> If you have any questions, please ask. As juju-core developers, I suggest
>> merging master into your feature branches as soon as possible to deal with
>> any
>> conflicts. And needless to say, "environment" is dead, long live "model".
>> So
>> please adopt the new terminology in your apis etc.
>>
>>
>>
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>