The cloud-compute relation uses the private-address setting to
reflect the hostname/address to be used for vm migrations. This
can be the default management network or an alternate one. When
this charm populates ssh known_hosts entries for compute hosts
it needs to ensure hostname, address and fqdn for the mgmt network
is included so that Nova resize operations can work if they use
the hostname from the db (which will always be from the mgmt
network).
Change-Id: Ic9e4657453d8f53d1ecbee23475c7b11549ebc14
Closes-Bug: #1969971
This new interface consumes information exposed by openstack-dashboard
to correctly configure nova-serialproxy and allow requests coming from
the web browser that tries to load the serial console.
Change-Id: I2d82abffb9649f16a792f180806cea36cc5e25df
Closes-Bug: #2030094
This change moves the default return value for the Keystone api_version
to 3.0 instead of 2.0. By this point in time, all supported OpenStack
releases use Keystone API version 3.0 instead of 2.0.
This was previously causing Nova templates to render with 2.0 in the
Keystone auth URL instead of 3.0, which caused auth failures.
Closes-Bug: 1995778
Change-Id: I6463a24fe4aaa654a58cff56720a55f0950db717
When taking the nova-cloud-controller from single unit to full HA by
increasing the number of units from 1 to 3 and relating it to hacluster,
the data set on the cloud-compute relation is not updated, because the
update_nova_relation() function is only called on
cloud-compute-relation-joined and config-changed, none of these hooks
are executed when scaling out the application.
This patch introduces a call to update_nova_relation() on
ha-relation-changed.
Test case on an environment deployed with a single unit of
nova-cloud-controller:
export NOVA_CC_VIP=10.0.0.11
juju config nova-cloud-controller vip=$NOVA_CC_VIP
juju deploy --series jammy --channel 2.4/stable hacluster \
nova-cloud-controller-hacluster
juju add-unit -n 2 nova-cloud-controller
juju deploy --series jammy memcached
juju add-relation memcached nova-cloud-controller
juju add-relation nova-cloud-controller nova-cloud-controller-hacluster
Change-Id: Ib08bf9b6e1ce2b69be4d99ffe0726b59d81f4bc9
Closes-Bug: #2002154
The linked bug shows the install of the charm with openstack-origin set
to zed. This happens because configure_installation_source() causes the
openstack-release package to be installed *before* the zed cloud archive
sources are configured into /etc/apt and an apt update done. This means
that the openstack-release package says "yoga" despite the zed packages
actually being installed.
Then, on the config-changed hook, it sees that the installed version is
showing as yoga and tries to do an upgrade. This fails, as the charm
hasn't yet bootstrapped, and the charm tries to bootstrap after
upgrading the packages.
There's a few bugs here which are exposed, but the tactical fix is to
force the openstack-release to match the installed packages.
Closes-Bug: #1989538
Change-Id: Icdef04e25e74c0a18fd49997c5f5b0540d583f40
The charm looks for endpoint changes and restarts the nova-scheduler
when the endpoint changes. However, the nova-conductor also needs to be
restarted in order to pick up new endpoints.
Closes-Bug: 1968708
Change-Id: I18dee4eb46bd836805e60427c0afc508e2489111
nova-consoleauth was removed for OpenStack >= Train, this change will
remove the nrpe check associated with it when is_consoleauth_enabled()
returns False.
Change-Id: I891634fc8001597089312801b29a80336543f5f0
Closes-Bug: #1904650
SSH keys from nova-compute are now shared across all
nova-compute charm apps.
Closes-Bug: #1468871
Change-Id: Ia142eceff56bb763fcca8ddf5b74b83f84bf3539
Communicate to compute services the cross_az_attach config setting.
Since the cross_az_attach setting needs to be applied at the compute
node, update the relation settings to specify the cross_az_attach
policy configured.
Change-Id: I71e97453453d5d091449caf547e68c6455d091cf
Closes-Bug: #1899084
Note that part of this fix belongs in c-h, but let's add it here
as a tactical measure given we are practically frozen.
Enable TLS in the functional test for focal-ussuri and onwards.
Also switch to focal-ussuri as target for smoke.
Drop Trusty/Mitaka as it currently does not pass with symptoms
like https://bugs.launchpad.net/charm-nova-compute/+bug/1861094
Closes-Bug: #1911902
Change-Id: I7b12479ce3afb94a0fb21c26b1ac78736b81aba2
If an ep change trigger is recieved then also look for the
catalog_ttl key on the relation. If it is present then wait for
that long before restarting services, this allows stale ep
entries to expire from the catalogue before restarting.
Change-Id: Ief2fa8286d9fa8058b7a012ec719776c4dd302f5
* charm-helpers sync for classic charms
* charms.ceph sync for ceph charms
* rebuild for reactive charms
* sync tox.ini files as needed
* sync requirements.txt files to sync to standard
Change-Id: Ie7640826be5426157c57877348cef43ab6067543
As witih the shared-db hook do not run db updates if the database
is in maintenace mode
Closes-Bug: #1866864
Change-Id: I65619271d8a4215c8d9bf68ad0a86136ad87011c
Currently the charm masks all services on db departed. The consequence
of which is that when a db relation is re-joined these services are not
started back up.
In addition, it stops all services, including memcached and haproxy,
which also do not get restarted on a db re-join.
This change selectively stops but does not mask services that pertain
directly to nova. So that on db joined the correct services get started.
Change-Id: I81f59c97b33edd5c3e67c379cfdee8f26509075a
Request to be informed of changes to placement and neutron changes.
If a placement change occurs restart nova-scheduler as it will
cache the old endpoint url and tell nova-compute to restart its
services as they will have done the same.
Change-Id: I7537723e40a5a25672fbbdc2d5c3144724f6240a
Closes-Bug: #1862974
If the database is in maintenace mode do not attempt to access
it.
Depends-On: I5d8ed7d3935db5568c50f8d585e37a4d0cc6914f
Change-Id: I7d5b7a20573b38d12b1ead708ee446472f21e9f8
If nova-compute is contected to the message broker before
the nova-conducter then it times out after a minute and shutsdown.
The nova-cloud-controller needs to inform the nova-compute charm
to restart nova-compute when it is connected to the message broker.
The restart is limited to the leader to stop multiple restart
requests.
Change-Id: Icdf47ea80267d421ca14f131f2d1f7cbdeb73641
Closes-Bug: #1861094
Essentially, the functions returning the related units and expected
units (for goal state) might not be sorted, something the author of
the code (me) hadn't taken into account. This fixes that by comparing
sorted lists.
Change-Id: I5c7bfe39b80f103e95fd5105d2185a89975ec23c
Closes-bug: #1859050
This new config called spice-agent-enabled is added to inform the spice agent
is not installed in the guest instance, which in conjunction with an image
property hw_pointer_model=usbtablet allows accurate position of the mouse in
Windows guests.
This option is not rendered in the nova.conf local to nova-cloud-controller
units, instead it's passed to related nova-compute units.
Change-Id: Id64699b6d04aa05935b31d55532df45c6d973fa7
Depends-On: https://review.opendev.org/699461
Closes-Bug: #1856602
As of OpenStack Train, the placement charm manages the placement API, and it
is no longer managed by nova-cloud-controller. This requires the placement
charm to be deployed and related to nova-cloud-controller prior to upgrading
nova-cloud-controller to Train.
This patch ensures that if an attempt is made to upgrade nova-cloud-controller
from Stein to Train, and placement is not yet related, it will block and
prevent the upgrade.
Change-Id: I217adfb59aed2e509a56b6559a528ae4c0adaa48
Closes-Bug: 1848529
The Nova console authorization has been moved to the database
backend and the separate service and package is no longer
necessary.
Change-Id: I672ae9538dc687a1c868bf99001041a54241ec24
Closes-Bug: #1848478
The placement project has split from nova into its own project
in Train. This patch disables the nova placement API as of Stein
when the placement charm relatation joins, and discontinues
nova placement installation as of Train for new installs.
Change-Id: If7c37ef8936e418b5afd21d83c9322563348cbcf
Needed-By: https://review.opendev.org/#/c/687915/
Partial-Bug: 1811681
This patchset implements policy overrides for nova-cloud-controler.
This change includes a charm-helpers sync to bring in the policyd helper
code.
Note there are no functional tests for this feature as the charm still
uses the old style non-zaza amulet framework. The Related-Bug below is
tracking this issue.
Change-Id: Ia5f3f8189d4a7b7b46a827707d964ebe40740aeb
Closes-Bug: #1741723
Related-Bug: #1845639
If console_access_protocol was switched to none then
console_access_protocol was not set at all by the relation set
acting on the relation with the compute nodes. This meant the
operator had no mechanism to unset console_access_protocol. This
change explicitly unsets it so the change is passed to the
compute units.
Change-Id: Ifdca0ec6626732ee0ea30a6847130ea97478df6f
Closes-Bug: #1844356
This change adds caching for the host look ups associated with a
private-address of a unit. This cache is maintained across hook
invocations, and is designed to reduce the time spent in
cloud-compute-relation-changed hooks (which occur as nova-compute units
join and update on the cloud-compute relation).
The feature has been added under an EXPERIMENTAL config flag (with the
default being "don't use the cached values") in case there are any
corner cases around DNS resolution in the deploying cloud during
deployment.
An action is included to allow clearing of the cache at unit,
application and whole relation level. This clears the cache and
re-triggers the host resolution, and relation updates. This is in case
of either 1) DNS changed during the deployment, 2) DNS has been altered
during the running of the cloud.
Change-Id: I5a68bf4c30bf1591184d660d50559c969822ddcf
The main driver here is to separate the concerns of resolving host names
and adding them to service/user related files. This is to enable the
(eventual) resolution of the feature to allow migrations across
relation ids (i.e. between nova-compute applications) and to enable
caching of hostname look ups.
Change-Id: I406d1daacbcc74eb6f3e090f9a46e01dd3e19cc8
The domain is missing from the credentials that nova cloud
controller passes to the compute nodes. This change adds it in.
Closes-Bug: 1830536
Change-Id: I2ad82b9b271d83e1b49691187c620d7b976e5ff0
If goal state is available, this patch uses it to defer distributing the
known_hosts and authorized_keys to the related nova-compute units until
the last nova-compute unit expected has joined and triggered a
cloud-compute-relation-changed hook. This means that all of the hosts
have been scanned and thus the whole group (per relation id) can be set.
Note that this patch does not unify the known_hosts/authorized_keys
files across relations. That's for a separate patch.
Change-Id: I6c26ebbad2236e66c174ef4606828db834803865
Related-Bug: #1833420
The (already) refactored region notification code checked for the
'region' value in the remote unit, despite the nova-compute charm not
setting the value. This has been removed. Now that the function only
needs to be set for the relation, it is no longer included in 'unit'
loops.
The utility function is also renamed to
set_region_on_relation_from_config to better reflect it's actual
function.
Change-Id: I81d9924bebe4009119505b1d5dccf2e498925c7e
Related-Bug: #1833420
Refactor ssh_known_hosts_lines() and ssh_authorized_keys_lines to be
easier to maintain and only call rstrip() once (per function).
Change-Id: Id2774bb1551e4826a2fd71d1a371d65ab2439a7d
This patchset refactors the update_ssh_keys_and_notify_compute_units()
into two separate halves: one is "update keys and hosts from a specified
unit on a relation (or the current relation/unit for the hook)" and the
other is update the relation_set data for the relation with the found
keys/hosts.
This is a precusor patch to reducing the number of dns queries and
setting of relation data, and to eliminate repeated operations on the
same data/result (which currently happens).
Change-Id: I45bc9a889968796572a61c199ac25d543c064670
Related-Bug: 1833420
The compute_changed() function (which handled the cloud-compute relation
changed hook event) was also used in the config-changed and update-charm
hooks. This meant that it did a lot of work that wasn't necessary for
those hooks.
This patch splits the function up into separate functions that deal with
one thing, and then introduces a new function to call those. This means
that the other usages compute_changed() now use the actual features that
they need.
Change-Id: I59e52076480729beec9e125f66714a208303908d
Related-Bug: 1833420
Essentially, remove a set_relation() call as the data bag that
get_compute_config() returns is used in an identical style
set_relation() call. This removes the output side-effect from
get_compute_config(), making it a little easier to reason about.
Change-Id: Ia6cd2976f7b8577d86e68c27707e8efe13843ef8
The nova-api (commit 962790239b)
introduced a 'nova-api' ready relation, but it was never added to the
metadata.yaml and it has never been used. This commit removes it, as
there is no need for it after 3 years, and it therefore has a
maintenance burden, even if not being used.
Change-Id: I6b13e2639b808fd640a6f8d892d1e3dd58215361
When using DVR and L3HA neutron deployment options,
Nova API Metadata requests are served from compute nodes,
instead of from neutron-gateway nodes.
This change allows nova-cloud-controller to send vendor_data
configuration values to nova-compute charm relation so it
can write to nova-compute's nova.conf appropriately.
Replaced the existing context logic with inheritance
from a new context created in charm-helpers, so the
logic can be shared across several charms that write
vendor metadata to nova.conf and vendor_data.json.
Also, small fix in the vendor-data and vendor-data-url
descriptions, where it was incorrectly stating that such
configuration would be effective in nova-cloud-controller
on Queens release.
The values set in vendor-data and vendor-data-url config
options will always be propagated to nova-compute regardless
of the OpenStack release. Those values will continue to only
be effective in nova-cloud-controller nodes on Rocky release
or later.
Included sync of charm-helpers code in order to inherit
the refactored vendor metadata contexts.
Change-Id: If8373fc6b2d04dbc29ed07896d385ac920cae3f4
Depends-On: I0c79e1bfac9fbe7009a7e862ad010cfa2de8cfda
Closes-Bug: #1777714
As with nova-compute the neutron-gateway needs to know if the CA
changes otherwise certificate validation will fail when it makes
calls out to other endpoints.
Change-Id: I45beef2521e8168d98482709a4d0196b6859db5c
If the certificates change then services needs to be restarted. This
change adds the SSL directory to the restart map to ensure any
certificate changes trigger a restart.
Also, if the certificates change we need to pass those on to
nova-compute.
Change-Id: I4cb2f760c26f0804d3cb7466c8aa741d5e0ec314
Closes-Bug: 1828530
The console proxy service run as user ``nova`` throughout its lifespan,
it has no load certificates before dropping privileges mechanism.
Set file permissions on certificate files to support this.
Sync charm helpers.
Closes-Bug: #1819140
Change-Id: I597b82070e51506c56500267daa2b59d8145b9f9
Check if console is enabled in this deploy before trying to start
console service. As part of this add a functions to determine whether
console is enabled and change existing methods to use them.
Change-Id: I91e2654bb0c5f89f51c703330ae2bd0a64cc84f3
Closes-Bug: #1820266
Remove support for single-nova-consoleauth operation; this option
managed a single instance of the nova-consoleauth process across
a cluster nova-cloud-controller application using the hacluster
charm. This proves somewhat racey on deployment as the ocf resource
deep checks the operation of nova-consoleauth including connectivity
to AMQP etc.. If the clustering of the service occurs before
other principle relations have been completed, the resource will
fail to start and the hook execution will spin, never returning.
HA deployments should always use memcached to share tokens between
instances of the nova-consolauth daemon; If the 'ha' relation is
detected, then ensure that a memcache relation is then required
for charm operation.
To support evaluation of the memcache relation completeness
the memcache specific code in InstanceConsoleContext was split out
into a new memcache specific class RemoteMemcacheContext.
Existing pacemaker resources will be deleted on upgrade; units will
move into a blocked state until a relation is added to memcached.
The nova-consoleauth service is resumed on upgrade to ensure that
instances run on all nova-cloud-controller units.
Change-Id: I2ac91b2bd92269b761befeb7563ad01cc5431151
Closes-Bug: 1781620
Due to an issue in python3 oslo_cache+eventlet when using
memcached. As workaroud for Rocky it has been decided to run service
nova-api-os-compute from systemd to apache2.
Closes-Bug: #1812672
Depends-On: https://review.openstack.org/#/c/633218
Depends-On: https://review.openstack.org/#/c/633482
Change-Id: I3bf279638c5decf1020345f3d2e876e379144997
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
Currently we directly use the one provided by charmhelper which does
not allow to reuse it for an other service. In this commit we symlink
a new template called wsgi-placement-api.conf to
charmhelper/../wsgi-openstack-api.conf.
The disable_package_apache2_site() call has been added in
do_openstack_upgrade() since previously it was not necessary to have
it during this step.
The disable_package_apache2_site() call has been added in
upgrade-charm to ensure that we remove old wsgi config for users which
are already using bionic-rocky and are upgrading their charm.
Partial-Bug: #1812672
Change-Id: Idc3cad9304eaf9b610db20650c32cd754f016358
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@canonical.com>
Use the generate_ha_relation_data helper from charmhelpers to
generate the data to send down the relation to the hacluster
charm.
This results in a few changes in behaviour:
1) The charm will no longer specify a nic name to bind the vip. This
is because Pacemaker VIP resources are able to automatically
detect and configure correct iface and netmask parameters based
on local configuration of the unit.
2) The original iface named VIP resource will be stopped and deleted
prior to the creation of the new short hash named VIP resource.
Change-Id: I7018e94e75c7c873c6c610b06d3e7cc9fedcc507
On charm upgrade the charm may switch to py3 packages. If so, ensure
the old py2 packages are purged. If the purge occurs then restart
services.
Change-Id: I984a227b3fe12a0086c926ae69c27d6e4d9741d3
Closes-Bug: 1803451
Disabling the single-nova-consoleauth while the unit is paused
will restart the nova-consoleauth service on the local unit.
This patch only resumes the service locally if the local unit
is not currently paused.
Change-Id: Id66375ab758e1b33b96a819d2ce788a4434b1686
Related-Bug: #1765215
Related-Bug: #1705514
Edward Hope-Morley