_ows_check_services_running was made public without the underscore and
it's private function name was made an alias and marked deprecated by:
https://github.com/juju/charm-helpers/pull/658
Switch to the new name to avoid many deprecation warnings being printed
by dependant charms every time update-status hooks run:
DEPRECATION WARNING: Function _ows_check_services_running is being
removed on/around 2022-05 : use ows_check_services_running() instead
Change-Id: I4758330db81a95ac2aa17f9bc316afdc2eab2d44
This is to enable caracal charms.openstack charms to test correctly as
caracal can be appropriately mocked.
Change-Id: Iea9d2aed7968dda0235694f3a9d73bad1573067c
Caching the charm OpenStack version will cause undesired behaviors
if the charm is a subordinate. The charm local cache is firstly
populated during the charm install. If the charm is a subordinate,
the version will remain the same regardless of future OpenStack
upgrades because today, the hook that updates the cache to the new
version in only called for principal charms.
Related-bug: #1949074
Change-Id: I76abbd29ca910fe4c4d62da09e2d2dd3b5c798a6
If the charm class defines haproxy healthcheck endpoints for api
exposing services render them into the haproxy template.
An example declaration would be as follows
class MyCharm(HAOpenStackCharm):
...
healthcheck = {
"option": "httpchk GET /healthcheck",
"http-check": "expect status 200"
}
Closes-Bug: #1880610
Change-Id: I0de1e45aad9db4d450f3e38e95868580537461e6
The keystone interface rebase to the Endpoint base class re-uses
the auto_accessors approach from RelationBase which makes the
interface smell a little different to other Endpoint based interfaces.
Check and map any keys listed in auto_accessors for all relation
class types rather than just for RelationBase.
This also fixes a minor issue where self.accessors was reset to []
when the auto_accessors attribute was not found in the relation
overwriting any accessors passed in during object construction.
Change-Id: I4481c6d8ad5c9f0a8bc5e892d1d7472be83f3454
The existing method of using a property to lazily load the cluster
relation adapter permanently changes the class to include that as
a cluster property. This means that a future (in the same hook
execution) instantiation of the class would include that property,
which means that 'real' cluster adapter could not be used. Sadly,
this was happening with the manila charm, and possibly others.
This patch changes it from a lazily loaded property, to a simple
attribute.
Change-Id: I704f362e0dd845ff00d0f0470b0235a4dead5f9f
Closes-Bug: #1981736
In the OpenStackAPIRelationAdapters class, the _resolved_cluster member
is used to determine the cluster relation had been resolved. However,
it's possible that it is accessed prior to be used as it was originally
an dunderscored method (__method). This patch makes it more robust by
switching to a single-underscore (which is inherited and not class-
mangled) and that it is always set to None initially in the __init__
method.
Change-Id: I9b119ba6848923c27844a2f758ae9e3c34c7722d
Closes-Bug: #1981736
Aparently this has been in the codebase since forever, and the
gate has now started to choke on it with this error message:
charms_openstack/charm/defaults.py:170:80: E501 line too long (82 > 79 characters)
Change-Id: I0dd61242527c7f1d93df130810bb08269a4312b4
Add config_property_with_config_flags observer to handle extra option.
The config-flags are comma separated list of key-value pairs.
Change-Id: I74a693df95bebb14a6edcb796f1c8e6b17a95317
This change adds a new `trilio_compat_version` that can be used
in templates when an option is gated on the trilio Major and
Minor version. The config option cannot be used for examining
atch versions as it relies on a float representation of the
package version.
Change-Id: I9221188b817fbb570700406b97e194aacf6ef786
The Trilio 4.2 changes the way that hashes are generated for nfs
mount points. The hash is now generated from the directory only,
the source IP address is ignored. This patch updates the ghost-share
action to accommodate that.
Change-Id: I64a1cc95a3a78ce79d57f5b840edb29996f04f9c
The ``get_os_codename_package`` function will be called by all
charms. The newly added call to the ``configure_source`` method
may in some circumstances raise an exception due to missing
source configuration option.
Handle this situation gracefully.
Related-Bug: #1951462
Change-Id: I2bb9c2561b89fea366bd7b7f6a10c3140ce09000
The current code will oportunisticly attempt to install the
``openstack-release`` package, but it does so without configuring
the UCA sources.
Attempt to configure sources to avoid charms getting stuck in a
chicken and egg situation.
Closes-Bug: #1951462
Change-Id: I8ed6e2dfc7ce83c2e56fd072458e2ef189968e41
To resolve a inter-dependency issue between the various package
version helpers and the UCA ``configure_source`` method, co-locate
all of them in ``BaseOpenStackCharmActions``.
Partial-Bug: #1951462
Change-Id: If42ad980ff2b0430eba24531eae9a80204768388
The package-upgrade action is similar to the openstack-upgrade
action except that it performs package upgrades within the current
openstack release. If a new openstack release is available, the
package-upgrade action will not perform any upgrades.
Change-Id: Ie783f8da67494f31abe574d99b1f2433dc622be9
The mock third party library was needed for mock support in py2
runtimes. Since we now only support py36 and later, we can use the
standard lib unittest.mock module instead.
Change-Id: I491ca9f482a00b7ca3fa44aa8c26ef73559c178f
When the vip is changed the ones that are no longer present need to be
registered for deletion from pacemaker's configuration. This change
relies on hookenv.config.changed() to determine what vip(s) are no
longer present in the configuration and ask hacluster to remove them.
Closes-Bug: #1952363
Change-Id: I1afe987ff26af0e10604dd507daef4ac282d9aab
The use of function maybe_do_policyd_overrides_on_config_changed
is deprecated in favor of maybe_do_policyd_overrides.
This would trigger deprecation warning messages not only in logs
but also in actions such as seen in Octavia Charm
The unittest covering the call has also been updated accordingly
Closes-Bug: #1939840
Change-Id: Iec91d60727533e6291c3ec20442197ac44f4607c
The use of package versions to look up OpenStack codenames is
deprecated for in favor of using the openstack-release package.
The openstack-release package is available for Wallaby onward.
Change-Id: I9038c9785a4f36b854a1fb7e8d5baaf91a99c70e
For principal - subordinate plugin type relations where the
principal Python payload imports code from packages managed by a
subordinate, upgrades can be problematic.
This helper will allow a subordinate charm to inform its principal
about all implemented release - packages combinations ahead of time.
With this information in place the principal can do the upgrade in
one operation without risk of charm relation RPC type processing at
a critical moment.
Related-Bug: #1806111
Change-Id: I455501c1c2cdb53e62b533be95d2493bf1a5027a
Switch to using restart_on_change from charmhelpers rather than
duplicating the code in charms.openstack.
I have run designate smoke with this change: https://paste.ubuntu.com/p/ZyQmyK92Yr/
Change-Id: I4925243747dd00471bc828c65278dd16ed951b0c
Charms consuming Ceph storage typically follow the convention that
pools are named for the application rather than the service name. Most
charms also allow for the pool name to be defined via a config option.
Charms which inherit from the BaseOpenStackCephCharm class will not
follow this typical behavior as the pool created is based on the charm
name.
This change updates the create_pool function to allow for a concrete
charm to optionally provide the name of the pool to be created,
defaulting to the application_name if one is not provided. This is a
change in behavior as the previous behavior was to use the charm
class's name property. Reviewing all known charms which inherit
from/mixin the BaseOpenStackCephCharm reveals that Gnocchi is the only
user of the create_pool method.
As such, it stands to reason that a change in behavior is safe in this
context since the charm class's name for gnocchi was set to the
'gnocchi' which is also the typical application name.
Change-Id: I1756ff4e1362fbc7584551249c583f8d3cb0c8dc
Closes-Bug: #1918821
When fetching CNs from bindings, skip those that are not
available since not all charms have all bindings.
Closes-Bug: 1913313
Change-Id: Iad9616d3f8668782cd9c7dc498120536fb756da7
In the linked bug, the designate charm ended up with the wrong IP
addresses in the haproxy.cfg due to the method add_default_addresses()
overwriting the correctly determined addresses obtained by the method
add_network_split_addresses().
It's not clear whether this has always been broken, and recent tests
have exposed it, or whether changes in charms.reactive have resulted in
add_default_addresses() adding more addresses than it used to.
However, it seems correct that the default addresses are added first and
then the ones from the relations/spaces add/overwrite the default ones
to provide the correct set.
Change-Id: Id7f1d457911374620e9a7ee3069376a1752160f5
Closes-Bug: #1912505
Reactive charms use charms_openstack.test_mocks to setup their
mocks. A recent change imports 'charmhelpers.contrib.openstack.ip'
so add that to the mock list
Change-Id: I3bd2517959b1cd43e057f420c8c4f2f28598d70a
In Juju 2.8rc3 unit-get public-address became unreliable
(Bug #1910973). Since getting an address this was is deprecated
switch the OpenStack functions to prefer network-get. However,
fallback to the old method to support old versions of Juju for
the time being.
Change-Id: I33020deefa1f814b77767653dad34c228def91fa
Adding support for Trilio 4.1 includes the following changes:
* Add Trilio_properties config property to enables templates to
distinguish between 4.0 and 4.1 release.
* Add get_trilio_codename_install_source to attempt to derive the
Trilio version supported by an apt repo.
* Add get_trilio_charm_instance which overrides the default
get_charm_instance. This will pick the correct charm class based
on both the Trilio release and the OpenStack release.
* Add select_trilio_release which overrides the default
select_release and calculates the target OpenStack and Trilio
release.
* Add a specialist Trilio metaclass BaseTrilioCharmMeta. This
registers charm classes using their OpenStack release, Trilio
release and package type.
* Move code shared between TrilioVaultCharm &
TrilioVaultSubordinateCharm to TrilioVaultCharmMixin. Add support
for Trilio upgrades to TrilioVaultCharmMixina.
NOTE: An earlier version of this change
(I5a5e5721d9a713b66f8c796896c400481e9733a2) was landed and
reverted. It was reverted because get_trilio_charm_instance
and select_trilio_release were both registered as handlers
irrespective of whether a charm explicitly imported
charms_openstack.plugins.trilio This caused reactive charms
which used the default handlers to fail as they imported the
Trilio functions and the default ones and only one can ever
registered. This patch fixes this by wrapping the trilio
function definitions inside make_* methods, so the decorator
only registers the methods when the make_* methods are
explicitly called.
Change-Id: Id3bb13aff6d0e6df2d5ec144689c992cf09c1b4c
This reverts commit 3b72a8ba2f.
Reason for revert: Registering a second release_selector_function is breaking non-trilio charms
Change-Id: I5a4b8f8602c2a46b340765a8a22fdc218560dfc6
Adding support for Trilio 4.1 includes the following changes:
* Add Trilio_properties config property to enables templates to distinguish
between 4.0 and 4.1 release.
* Add get_trilio_codename_install_source to attempt to derive the Trilio
version supported by an apt repo.
* Add get_trilio_charm_instance which overrides the default get_charm_instance.
This will pick the correct charm class based on both the Trilio release and
the OpenStack release.
* Add select_trilio_release which overrides the default select_release and
calculates the target OpenStack and Trilio release.
* Add a specialist Trilio metaclass BaseTrilioCharmMeta. This registers
charm classes using their OpenStack release, Trilio release and package
type.
* Move code shared between TrilioVaultCharm & TrilioVaultSubordinateCharm
to TrilioVaultCharmMixin. Add support for Trilio upgrades to
TrilioVaultCharmMixina.
Change-Id: I5a5e5721d9a713b66f8c796896c400481e9733a2
Allow a charm to use the new register_get_charm_instance decorator
to register the method to be used when getting a charm instance.
Currently get_charm_instance expects standard OpenStack
versioning, this change allows are a charm to register an
alternative get_charm_instance method that can handle an
alternative versioning system.
Perhaps controversially the default method is not defined in
charms_openstack.charm.defaults. I have kept it in core
because it felt a more natural fit there given it relies on
core._releases but I am open to moving it if that is
preferable.
Change-Id: I42574654bc1f314b49049e80861d4039f8484dff
Break out the collection of a packages version information from
deriving the corresponding OpenStack release. This allows the package
version code to be used with charms which have their own
idiosyncratic versioning system.
Change-Id: I9a7dcc6ad3da8860dc650f956e5c6eec8ff51660
Added test case to verify RuntimeError is raised when release_pkg is not set.
Closes-Bug: #1904494
Change-Id: I421b52d502644b52f4e31162e74dea8a1befdfa0
The new helper supports to optionally retrieve common
configuration options for BlueStore Compression.
Fix ordering of Ceph class composition. Both the CephCharm and the
fake charm class used in the unit test had the wrong order for the
composition making it impossible to override already existing
methods inherited from OpenStackCharm.
Change-Id: I9fb543f297522c7217acdcfa950bb2810b26c4a0
If a charm class sets ssl_port_bump to True then when configuring
the service for TLS also change the port it is listening on.
The need for this comes from the nova-scheduler and nova-compute
services which cache the url for the placement service, when the
placement service switches protocol the nova services fail which
does not trigger them to reexamine the catalogue.
Closes-Bug: #1862974
Change-Id: I790c55e78439b9a5ea2c3f12edbe5928a4f08e05
Ensure that TLS is potentially reconfigured in the event of a
config-changed hook execution - ssl_* configuration options may
have been changed so certs, keys and CA files on disk will need
to be updated.
Change-Id: I00d2eb16714785b15e13b196ea12716dc8a5b527
Related-Bug: 1865842
Co-Authored-By: James Page <james.page@ubuntu.com>
Trent Lloyd