Known issues

Known issues

This section lists the MCP 2019.2.5 known issues and workarounds.


[32334] Glusterd is not started back after being killed

The Glusterd service does not restart automatically after its child processes failed or were unexpectedly killed.

Note

Re-apply the provided workaround if any of the GlusterFS packages has been re-installed or upgraded.

Workaround:

Caution

Perform the procedure on each KVM node in your deployment.

  1. In the /lib/systemd/system/glusterd.service file, set the Restart option in the [Service] section:

    [Service]
    ...
    Restart=on-abort
    ...
    

    The recommended values include:

    • on-abort

      The service restarts only if the service process exits due to an uncaught signal not specified as a clean exit status.

    • on-failure

      The service restarts when the process exits with a non-zero exit code, is terminated by a signal including on core dump and excluding the aforementioned four signals, when an operation such as service reload times out, and when the configured watchdog timeout is triggered.

  2. Apply the changes:

    systemctl daemon-reload
    

[32510] Networking does not work after compute reboot

After reboot of the compute node in the MCP OpenStack deployments with Neutron OVS VLAN tenant networks with network nodes and without a Distributed Virtual Router (DVR) on the compute nodes, Open vSwitch blocks the br-prv bridge system ports such as br-ctl, br-mesh, and br-storage. The affected compute node loses connectivity with all infrastructure that include services’ APIs, databases, storage, and VXLAN members.

The affected configuration:

OpenVSwitch:
  - bridge: br-prv
      ports:
        - bond0
        - br-prv: internal
        - br-ctl: internal, options: tag=43
        - br-mesh: internal, options: tag=200
        - br-storage: internal, options: tag=30

The workaround is to separate the br-prv ports from the system ports and use the br-sys linked OVS bridge to control these ports.