Skip to content

docs: add instance-recovery/cluster-refresh snap interface limitation #222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hemanthnakkina wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: add instance-recovery/cluster-refresh snap interface limitation #222

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .custom_wordlist.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,6 +182,7 @@ idp
infrastructure
init
initiator
instantiation
intra
ippool
isolCPUs
Expand Down
6 changes: 6 additions & 0 deletions how-to/operations/cluster-upgrades.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -112,6 +112,12 @@ charms:

sunbeam cluster refresh

.. note::
If the ``instance-recovery`` feature is enabled, running a cluster refresh
may leave the ``openstack-network-agents`` and ``openstack-hypervisor``
charms in a blocked state on compute nodes. See
:ref:`Known limitations` for details and the workaround.

If the snap has been refreshed to a different risk level in its channel
(for example, from ``stable`` to ``beta``) since the last update, the command
will prompt you to confirm before proceeding. In this case, it is recommended
Expand Down
18 changes: 15 additions & 3 deletions reference/known-limitations.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,18 @@ This document describes the known limitations of the Sunbeam project.
- Clusters bootstrapped with ``snap-openstack`` versions earlier than
**rev998** will continue to experience intermittent API failures (for up
to 5 minutes) when a control node becomes unavailable. A known
`k8s charm limitation <https://charmhub.io/k8s/configurations#kube-apiserver-extra-args>`_
restricts updates on active deployments, meaning this issue cannot be
fixed on clusters deployed prior to this revision.
`k8s charm limitation <https://charmhub.io/k8s/configurations#kube-apiserver-extra-args>`_
restricts updates on active deployments, meaning this issue cannot be
fixed on clusters deployed prior to this revision.
* - Enabling the instance-recovery feature blocks the
openstack-network-agents and openstack-hypervisor charms
- `LP #2147411 <https://bugs.launchpad.net/snap-openstack/+bug/2147411>`_
- Enabling the ``instance-recovery`` feature can leave the
``openstack-network-agents`` and ``openstack-hypervisor`` charms in a
blocked state on compute nodes, as the parallel instantiation of
consul-client snaps disrupts the snap interface connections to
MicroOVN ``ovn-chassis`` endpoint. As a workaround, disconnect and
reconnect the ``ovn-chassis`` interface on the
``openstack-network-agents`` and ``openstack-hypervisor`` snaps, or
reboot the affected host. This issue can also be triggered by running
a Sunbeam cluster refresh.
Loading