v1 login (and v0) are still there more or less for that purpose (but not done 
yet).

Actually, the login api is the only api that has not had a version bump. We
still have v2 as it existed in 1.25. That will need to be fixed as it got 
missed.


On 04/02/16 13:58, John Meinel wrote:
> 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" <[email protected]> wrote:
> 
>> Thanks for this in-depth break-down, Ian.  It really helps.
>>
>> -eric
>>
>> On Tue, Feb 2, 2016 at 6:33 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
>>
> 

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

Reply via email to