OpenStack known issues¶

This section lists the OpenStack known issues with workarounds for the Mirantis OpenStack for Kubernetes release 21.5.

[6912] Octavia load balancers may not work properly with DVR
[16495] Failure to reschedule OpenStack deployment pods after a node recovery
[16452] Failure to update the Octavia policy after policies removal
[16103] Glance client returns HTTPInternalServerError error
[19065] Octavia load balancers lose Amphora VMs after failover

[6912] Octavia load balancers may not work properly with DVR¶

Limitation

When Neutron is deployed in the DVR mode, Octavia load balancers may not work correctly. The symptoms include both failure to properly balance traffic and failure to perform an amphora failover. For details, see DVR incompatibility with ARP announcements and VRRP.

[16495] Failure to reschedule OpenStack deployment pods after a node recovery¶

Kubernetes does not reschedule OpenStack deployment pods after a node recovery.

As a workaround, delete all pods of the deployment:

for i in $(kubectl -n openstack get deployments |grep -v NAME | awk '{print $1}');
do
kubectl -n openstack rollout restart deployment/$i;
done

Once done, the pods will respawn automatically.

[16452] Failure to update the Octavia policy after policies removal¶

Fixed in MOS 21.6

The Octavia policy fails to be updated after policies removal from the OsDpl CR. The issue affects OpenStack Victoria.

As a workaround, restart the Octavia API pods:

kubectl -n openstack delete pod -l application=octavia,component=api

[16103] Glance client returns HTTPInternalServerError error¶

Fixed in MOS 21.6

When Glance is configured with the Cinder back end ^TechPreview, the Glance client may return the HTTPInternalServerError error while operating with volume. In this case, repeat the action again until it succeeds.

[19065] Octavia load balancers lose Amphora VMs after failover¶

Fixed in MOSK 22.3

If an Amphora VM does not respond or responds too long to heartbeat requests, the Octavia load balancer automatically initiates a failover process after 60 seconds of unsuccessful attempts. Long responses of an Amphora VM may be caused by various events, such as a high load on the OpenStack compute node that hosts the Amphora VM, network issues, system service updates, and so on. After a failover, the Amphora VMs may be missing in the completed Octavia load balancer.

Workaround:

If your deployment is already affected, manually restore the work of the load balancer by recreating the Amphora VM:
1. Define the load balancer ID:
```
openstack loadbalancer amphora list --column loadbalancer_id --format value --status ERROR
```
2. Start the load balancer failover:
```
openstack loadbalancer failover <Load balancer ID>
```

To avoid an automatic failover start that may cause the issue, set the heartbeat_timeout parameter in the OpenStackDeployment CR to a large value in seconds. The default is 60 seconds. For example:

spec:
  services:
    load-balancer:
      octavia:
        values:
          conf:
            octavia:
              health_manager:
                heartbeat_timeout: 31536000