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 <[email protected]> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
