Thanks for this in-depth break-down, Ian. It really helps. -eric
On Tue, Feb 2, 2016 at 6:33 PM, Ian Booth <ian.bo...@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@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