The certificate handler code does a bit of work and should not
run during the update-status hook.
As documented in the charms.reactive dispatch [0] function
handlers registered with the @hook decorator will execute before
other handlers. So we can rely on the 'is-update-status-hook'
flag being consistently set when in update-status hook before
other handlers are evaluated for dispatch.
0: 3d27f3d24a/charms/reactive/bus.py (L325)
Closes-Bug: #1954748
Change-Id: I4a3aa544f98049c83db576f95de826038e8e1afc
For principal - subordinate plugin type relations where the
principal Python payload imports code from packages managed by a
subordinate, upgrades can be problematic.
This change will allow a subordinate charm that have opted into the
feature 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: I2df0abed25825448569581273aee4e79a6003dad
This flag is to enable charms.openstack / layer-openstack charms to have
a way to determine if the current hook is update-status from a flag. By
being a flag, it means that charm reactive handler code doesn't have to
check for the the hook in every handlers, but can declare "don't run
this if it's an update-status hook". The flag is guaranteed to not be
set during a not update-status hook (in that, if it is set, then it gets
cleared and the handlers can therefore run), or to be set during an
update-status hook. To speed things up, the code also removes the flag
at the end of the update-status handler.
The intended use of this flag is to guard 'expensive' handlers from
being run during update-status.
Change-Id: I7ca97db646ada95d7f5541ca4e2cf14013c0d7a6
When debugging a charm uprade issue with ovn_chassis, it was noticed
that the upgrade hook failed as the concrete charm class wasn't
found and instantiated. This patchset ensures that the concrete charm
class is found and thus can be instantiated.
Change-Id: Ic9cdc2f470e4c7e1f6fc17a4d6246ca79fc48bd7
These where moved up to this layer from ``layer-openstack-api``,
removal counterpart: I007275c041ca5465664a6b5d441e56c0316c405d
Guard the default handlers behind check for
'charms.openstack.do-default-certificates.available' flag. This
flag is activated when the consumer charm makes a call to
charm.use_defaults('certificates.available') from its reactive
handler. Previously it was always activated for all consumers of
the ``openstack-api`` layer, it should be up to the charm
implementation to choose.
We do not add back ``layer-tls-client``, the reason being that
the reactive bits in ``layer-openstack`` in conjunction with
helpers in ``charms.openstack`` is managing both the server and CA
certificates and rely on the same flags to detect changes.
If we one day offload those tasks to the ``layer-tls-client``
we should add it back in conjunction with removing our code for
this. At the time of this writing it would not be possible as
``layer-tls-client`` is not spaces aware.
With the above mentioned change we can stop relying on the now
deprecated ``certificates.batch.cert.available`` flag.
We also do not add back the Keystone certificates handling code
as this has been removed from the Keystone charm reference:
openstack/charm-keystone/commit/17b24e7fde8e4c8c276a4f392cbae0d1d0ed2615
Needed-By: I007275c041ca5465664a6b5d441e56c0316c405d
Needed-By: I8a72acd451dd21e1b042b7f71f6d98e164737ac1
Closes-Bug: #1840899
Change-Id: I12f45236632b608e07fdd35d31b90b84ca92eb1f
Add a default handler for storage-backend relation. This is part
of the work to push cinder plugin bolierplate code into supporting
layers.
Change-Id: Icad5f72939b1e33d15adf2638f8e344235a9318b
The version of the application deployed should be set on all
assess_status calls, not just during the 'update-status' hook
execution.
Remove call from update-status default handler (it will be
added to _assess_status in the core charm class).
Change-Id: Iac95a0b988ae6563039aae599985de5713432c00
Closes-Bug: 1715429
Due to commit 95493a4 in charms.reactive, the default handlers in
charms.openstack broke. This is because charms.reactive no longer will
run handlers that are not in the hooks/ or reactive/ directory tree; the
default handlers in charms.openstack are in the library code, which is
pip installed into the module packages.
This patch, and related patches in charms.openstack and
layer-openstack-api enable the default handlers to function again. Note
that from a charm author perspective, the API to default handlers is
identical. This is merely an implementation change.
Change-Id: I7feb7aed219728efd57b5878bb6a5ff9e204c52a
Partial-Bug: #1707685
This is part of the 'declarative helpers' change in charms.openstack
where 'boiler plate' state handlers have been migrated into the
charms.openstack module and can be optionally activated in a charm.
Change-Id: I28fa2a53cdc108ce7e8432b43d18697841012803
This bakes in the assess_status() to the update-status hook to call
assess_status() on the charms_openstack.charm.OpenStackCharm class.
This has the effect of determining the workload status for the
unit.
Change-Id: Idf9a712f818445ba9f68dccae2d98237eb7f7eee