When developing Juju we sometimes have to change various API server interfaces, most if not all of the time these are or should be compatible with previous versions of Juju clients. Pythonlibjuju (pylibjuju) can be considered one of these clients. Going forward the CI infrastructure will start to test if your Juju PR will cause any issues with the pylibjuju client, if changes have broken the client, additional work will be required to fix the python code before attempting to merge your changes. These could include new endpoints, changes to parameters or deprecation of old existing endpoints.
Syncing with Juju
If you’re going to introduce new methods that you want to expose in pylibjuju you’re going to have to update the schema file found within pylibjuju. Inside Juju is a schema file that is sync’d for every pull request and release of Juju. This schema file contains the current schema (think layout) of the apiserver. In practice we want to copy that schema file from Juju to pylibjuju and rebuild the client from that.
Ensure you have the correct Juju and that you have everything installed according to the Juju documentation. (see below for script as a hole)
- Firstly remove the previous juju latest schema symlink by doing:
- Copy the file ensuring to set
$JUJU_VERSIONin the following command to something sensible like
cp "$GOPATH/src/github.com/juju/juju/apiserver/facades/schema.json" "$HOME/python-libjuju/juju/client/schemas-juju-$JUJU_VERSION.json"
- Create a symbolic link to the schema you just created
ln -s schemas-juju-$JUJU_VERSION.json schemas-juju-latest.json
Then move back to the root of pylibjuju
make client- You should expect to see updates to the juju/client/_definitions.py file, as well as one or more of the juju/client/_clientX.py files, depending on which facades were touched.
Once syncing with Juju is complete you may need to integrate any new or changed API calls into the object layer, to provide a clean, Pythonic way to interact with the model. This may be as simple as adding an optional parameter to an existing model method, tweaking what manipulations, if any the model method does to the data before it is sent to the API, or it may require adding an entirely new model method to capture the new functionality.
In general, the approach should be to make the interactions with the model layer use the same patterns as when you use the CLI, just with Python idioms and OO approaches.
Ensure you replace
$JUJU_VERSION with a value.
rm ~/python-libjuju/juju/client/schemas-juju-latest.json cp "$GOPATH/src/github.com/juju/juju/apiserver/facades/schema.json" "$HOME/python-libjuju/juju/client/schemas-juju-$JUJU_VERSION.json" cd ~/python-libjuju/juju/client ln -s schemas-juju-$JUJU_VERSION.json schemas-juju-latest.json cd ~/python-libjuju make client
Pylibjuju is relatively painless to release as opposed to Juju release process. Below is a series of changes required for releasing pylibjuju.
Firstly you’ll need an account for https://pypi.org/ (long term we could use a generic juju account, short term create your own - don’t forget to turn on 2FA). Secondly you’ll need to be made an contributor/maintainer of the pylibjuju project - speak to @rick_h.
- Update the
docsfolder with the new version and relative information. Might be useful to mention if any facades where changed along with any new python features added.
VERSIONinside the root of the project.
- Create a new branch and get it reviewed before merging with the target branch (2.6 etc)
You are ready to release!
Ensure you’ve got everything set and ready.