The ceilometer compute agent uses the default polling.yaml
from the installed packages without the ability to configure its contents.
This change adds two configuration options: 'polling-interval' and
'enable-all-pollsters', borrowing from the implementation in
charm-ceilometer. We start off with a limited set of meters as before
and if these are not enough, the user can set 'enable-all-pollsters' to
'true' to collect all available 'Pollster' metrics as listed in the
documentation [1].
Verification:
I tested this change on a cluster built from the OpenStack base bundle
and the ceilometer and gnocchi charms. I confirmed that extra metrics
that originate from the Compute Agent pollster (e.g. disk.device.read.latency)
are available in gnocchi after setting 'enable-all-pollsters' to true.
[1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-measurements.html
Closes-Bug: #1914442
Change-Id: I21c9a93e7dd91bced9365e44f3e6a5315976c3bb
Prior to this change, the ceilometer-agent charm receives RMQ
configuration details via the ceilometer charm. This makes it
a bit of a snowflake.
Refactor RMQ integration to require a direct relation to the
rabbitmq-server charm; information provided on this relation
will superceed any information currently provided via the
charms relation with ceilometer, ensuring that there is no
disruption to service during a charm upgrade before the new
relation is added.
Switch to using [DEFAULT]transport_url for RMQ configuration,
making use of the new ch template for SSL and HA configuration
in [oslo_messaging_rabbit].
Change-Id: Ie637ec5162461826505cea39bde6829e036fa1f2
Closes-Bug: 1817672
Ceilometer has had an openstack-origin and supported upgrading
the Ceilometer version independently of the principle that it is
associated with. This can cause issues with clashes in package
dependencies between the two. This change makes the
ability for the agent to be upgraded independently of the principle
and instead has the upgrade triggered by the principle. This brings
this charm inline with the other OpenStack subordinate charms.
Change-Id: I641ac2168ac705191d916eaa0624214791e1745d
Closes-Bug: #1802400
Openstack mostly defaults to using public endpoints for
internal communication between services. This patch adds
a new option use-internal-endpoints which, if set to True,
will configure services to use internal endpoints where
possible.
Change-Id: I170e5e1eef3d2e3bb28d37606a468328005609d0
Closes-Bug: 1456876
Cornellius Metto