Juju terminology change: controllers and models

Ian Booth ian.booth at canonical.com
Wed Feb 3 01:33:45 UTC 2016


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.






More information about the Juju-dev mailing list