Currently interacting with functions in zaza.model requires the
model to be passed in. This has resulted in multiple calls to
get_juju_model(). It is cleaner to push these calls down into
the model wrapper and make the model_name an optional
argument. In addition, the current model name is now cached
without having to check the os.env each time.
Unfortunately this has resulted in the signature changing on a
great many function so this diff is bigger than would normally
be desirable.
Recently functions were added to zaza.model for adding and removing
models. These duplicated existing functions in zaza.controller.
Given these functions act against the controller, zaza.controller
feels like the correct location. In addition the implementations in
zaza.controller correctly handle disconnects which the new ones
did not.
This PR removes the duplicates and points any existing references
from zaza.model to zaza.controller. Finally, docstrings were added
and documentation links.
This pr adds a number of new fuctions to zaza.model. As discussed
zaza.model needs to be broken up as it has become too large. I would
like to continue the discussion around that and submit a subsequent
patch for that at a later date.
Without introducing mojoisms into zaza there are some changes that are
required to enable mojo's use of zaza.
The goal is to keep mojo specific utilities in openstack-mojo-specs and
to move any generalized tools here in zaza.
This change updates some generalized zaza tools to enable mojo to use
them.
* Add the ability to wait for bespoke statuses
This change adds the ability to wait for bespoke work load
statuses and messages. These are defined in the charms tests.yaml
* Add unit tests
* Remove debug print
* Fix typos and add checks for errored units
* Restore juju_wait as openstack_utils imports it
The vault charm action to authorise the charm within vault needs to
be run on the leader. This mp adds run_action_on_leader to support
that and updates the tests.
Add tests for the authorize-charm action on the vault app. To
support this add get_action method to return an applications
actions. However, this is not implemented in libjuju yet so
fallback to subprocess
Frode Nordahl
Chris MacNaughton
Liam Young
David Ames