Due to python-libjuju's requirement for coercing every config
value into strings, some configuration type/values are not
possible to specify the default for.
Allow the config_change helper to optionally use reset back to
charm default instead of specifying default config values in a
dictionary.
To support OVS to OVN migration checks we want the basic overcloud
configure job to set up N-OVS and/or N-GW when present and the
OVN pre migration configure job will copy the configuration for us.
When configuring the address to use to talk to Keystone,
the format_addr helper should be used to ensure that an
IPv4 or IPv6 address can be correctly handled.
The biggest change is that the upgrade_groups() is a list of tuples ...
[()] ... rathern than a collections.OrderedDict(). This tends to make
more sense as they are processed in order and don't actually need to be
indexed.
Also excludes easyrsa (as it's not an upgrade target) and adds a
"Database Services" which upgrades mysql or percona FIRST before moving
on to rabbitmq and other stateful services. This is because some charms
really need to talk to mysql if one of the other stateful services does
a relation changed hook. This makes it more likely that the system will
ugprade correctly.
Fix paramiko.ssh_exception.BadAuthenticationType when SSHing to a new Ubuntu instance.
Note that paramiko still has a few issues around authentication:
https://github.com/paramiko/paramiko/pull/1106/files
This paramiko PR also shows that password='' isn't the same as
password=None
This is the 3rd change in the effort to deprecate
zaza.openstack.utilities.juju in favour of zaza.utilities.juju.
All functions now just wrap their equivalents in
zaza.utilities.juju and a decorator has been added which logs a
warning if the function is used.
Because the OpenStack charms re-render their config
whenever things are incorrect, we can accept any new
package defaults as a part of the upgrade and
resolve incorrect config after the upgrade
Previous attempts to fix LP Bug#1784083 added a workaround (commit
820ed808) which is being removed here.
The root cause seems to be upstream in the dragent. It may never have
been envisioned to run the agent by itself the way the charm does.
So that even if neutron-api completes its amqp relation first,
neutron-dynamic-routing can still see
oslo_messaging.exceptions.MessagingTimeout errors. Some operation
must occur against neutron before dragent is truly ready. i.e. some post
deploy openstack command. So it is outside the purview of the charm.
This change adds a service restart late.
Partial-Bug: #1841459
Add zaza.openstack.utilities.juju.get_subordinate_units to get a list
of all subordinate units associated with units in unit_list.
Subordinate can be filtered by using 'charm_name' which will only
return subordinate units which have 'charm_name' in the name of the
charm.
