Zaza explicitly limits which environment variables are allowed for
template rendering. Allow the variables that OSCI actually uses. Without
this OSCI fails to render vips.
This enables zaza tests with HA in OSCI.
The local overlay ('local-charm-overlay.yaml') is generated on the
fly during deploy time and it assumes that the application name
will match the charm name. However this is not always the case so
allow charms to override the deploy time generated template with
one from the local tests/bundle/overlay directory.
This is really another stop-gap until the whole bundle generation
piece is rewritten.
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.
* 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
Add the testing required for neutron dynamic routing A.K.A dragent.
Create the zaza.charm_tests.dragent module for testing neutron dynamic
routing.
Create the zaza.configure module for reusable configuration tools.
Update utilities to simplify authenticating clients.
Stop requiring the charm to ship with a boiler plate overlay for
setting a relative path for local charm location. Instead render the
overlay from a string var. As part of this some of the template
rendering code was refactored.
This change adds support for model specific overlays from
templates which are rendered at deploy time.
The overlay template directory will be searched for a corresponding
template (<bundle_name>.j2). If one is found then the overlay will
be rendered using environment variables matching AMULET* or
ZAZA_TEMPLATE* as a context. The rendered overlay will be used on
top of the specified bundle at deploy time.
A default overlay is always applied "local-charm-overlay.yaml". This
overlay is only used to move the location of the charm being deployed
to a relative path so the bundle can use "charm: <charm name>" rather
than "charm: ../../../<charm name>"
juju_wait assumes it is working against the current model so
explicitly set the JUJU_MODEL env variable before calling it
to ensure it monitors the correct environment
* Add calls to asyncio.get_event_loop().close() to close loop. libjuju does
not do this for you and needs to be done just before exiting.
* Require model to be explicitly set when running command line tools. This is
part of the drive to ensure that eventually multiple runs can be performed
concurrently.
* Add set_juju_model/get_juju_model functions to manage which model is in
focus
Ryan Beisner
David Ames
Chris MacNaughton
Alex Kavanagh
Nicolas Pochet
Liam Young