It is possible for the version of a package to remain the same
across multiple releases of openstack so this adds support to
get_os_codename_package() to allow this.
If releases A, B and C have version N and we are on release B
this will return release C so that it does not look like there
is an upgrade necessary. The main change here that allows this
is to support matching major and minor version up to X.Y.Z as
opposed to previously only matching the major version X.
Related-Bug: #1973303
Change-Id: I138f61312efb728544276483b1a459b9eeecafdb
Charm instances where the release is > zed does not work using the
default_get_charm_instance. The keys stored in the _releases dictionary
are sorted in their alphabetical sorting order, thus causing releases
such as Bobcat to be treated as older releases than Zed.
This change causes the release names to be sorted using the
CompareOpenStackReleases object from the charmhelpers library. This will
ensure that the release names are sorted according the release order
rather than the alphabetical name.
Change-Id: I528a9dcc5511b74186132b57948e18e4f3a1ef0b
Master branches need to support py39 and py312 (non-voting)
based on governance for 2024.2 [0].
Removed old targets that are no longer needed in master.
[0] https://review.opendev.org/c/openstack/governance/+/908862
Change-Id: I46feebfe449d956c0b9e35e42209162fcec52c44
_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
Update tox.ini to include the py311 target as required by the current
openstack-python3-charm-jobs zuul template.
Change-Id: Iec0cad398f25e32fafdc064652f3d576b45e4550
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