charm-tools has received a few maintenance releases to adapt to new
releases of protobuf, this patch relaxes the pinning to use any 2.x
release of charm-tools.
To build lxml system packages are needed and they are added to
bindep.txt
[train] Ensure get_requests_for_local_unit doesn't fail on incomplete relation
This is a rebuild/make sync for charms to pickup the fix in charmhelpers to fix
any inadvertant accesses of ['ca'] in the relation data before it is available
from vault in the certificates relation. Fix in charmhelpers is in [1].
Tox 4.0.0 was recently released and it has several breaking changes.
We pin to < 4.0.0 here. We are planning to move forward only on the
master charm branches.
Tox is also pinned to < 4.0.0 for stable branches in upstream
openstack-zuul-jobs as well as in zosci-config. However, the
requires= section in the charm's tox.ini file ends up installing
tox>4, wiping out the zuul-pinned tox<4 that was already installed
installed. This patch fixes that.
The build.lock branch points to master which means that the layer is not
locked. Lock the layers to the commit hash instead; this ensures
reproducible builds as much as possible.
This is the main patch for the migration of the stable/21.10
charm to charmhub for the stable/train branch (train track on
charmhub). This patch initially supports bionic from queens
to train, and does not support ussuri. It supports upgrades
from bionic-queens to bionic-train (with each intermediate
step needed). Crucially it does NOT set a default
openstack-origin, which means installing train/stable
without specifying the openstack-origin will result in a
bionic-queens installation. This is intentional as the branch
covers queens to train.
* use stable/21.10 libraries
* use zaza/zaza-openstack-tests at stable/21.10
* build.lock files for reactive charms
* bundles refer to ~openstack-charms candidate channel
* update tox/pip.sh to ensure setuptools<50.0.0
All of the test bundles deploy ironic-api in HA with hacluster,
however the bundles were using individual overlays that required
new overlays to be defined for each new bundle. Instead, let's
use a single local-charm-overlay.yaml.j2. This handles the
situation similar to how charm-octavia does.
