path: root/book-enea-nfv-core-release-info/doc/known_bugs_and_limitations.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id="bugs-limitations">
  <title>Known Issues and Limitations</title>

  <para>Problems and limitations relevant to the current release are detailed
  in this chapter. Corrections to bugs detected by Enea are submitted
  upstream, and remaining issues are listed below.<remark>INFO: The <emphasis
  role="bold">Release-Specific Problems</emphasis> section further down is
  generated from JIRA with gen_known_issues.py, but that script is HARDCODED
  with affectedversion "Enea NFV 1.0.1" and needs to be adapted when a release
  info for another ENFV version changes.</remark></para>

  <section id="bugs-limitations-gen">
    <title>Release Specific Issues</title>

    <orderedlist>
      <listitem>
        <para>Live migration fails on ThunderX nodes with different CPU
        Revisions</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>For an aarch64 architecture, QEMU describes a CPU in terms
            of Vendor, Model and Revision number in contrast with the x86
            architecture, where CPU supported features (e.g. the instruction
            set supported) are used.</para>

            <para>QEMU lacks support in describing a CPU in terms of features
            for an aarch64 architecture, causing the migration of VMs between
            hosts with different CPU revisions to fail.</para>
          </listitem>

          <listitem>
            <para>Workaround:</para>

            <para>In the deployment pod use compute nodes with the same
            Vendor, Model, and Revision number CPUs.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Instances fail to boot when using a direct port (SR-IOV) on
        ThunderX</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>Deployment is successful with SR-IOV enabled interfaces
            however, instances fail to boot when a direct bound (SR-IOV) port
            is added. This has been tested using a SR-IOV capable PCI Express
            Network Interface. As a consequence it is impossible to
            passthrough a SR-IOV port on ThunderX.</para>
          </listitem>

          <listitem>
            <para>Workaround: N/A.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Security groups are not working correctly for ICMP traffic in
        deployments with OpenDaylight.</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <itemizedlist>
              <listitem>
                <para>When OPNFV is deployed with OpenDaylight as an SDN
                controller, the Security Groups rules pertaining to ICMP do
                not work as expected. The OpenFlow rules describing the ICMP
                rules are inconsistent, so VMs can be pinged even when this is
                not desired.</para>
              </listitem>

              <listitem>
                <para>This reproduces on aarch64. On x86 the security groups
                work correctly.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>Workaround: N/A.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Virtual instances do not get IP from DHCP in SFC scenarios with
        ODL</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <itemizedlist>
              <listitem>
                <para>After a fresh deploy of OPNFV with OpenDaylight and the
                Service Function Chaining scenario configurations, instances
                fail to get IP from DHCP, due to OpenDaylight
                malfunctioning.</para>
              </listitem>

              <listitem>
                <para>The SFC VNFs are not reachable via SSH for management
                and configuration.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>Workaround: Restarting OpenDaylight via
            <literal>systemctl</literal> fixes the problem.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Scale-in and Scale-out operations are not supported</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <itemizedlist>
              <listitem>
                <para>When adding or removing nodes via Fuel installer on an
                OPNFV deployment that uses OpenDaylight, flows in
                <filename>ovs</filename> tables on the existing and new nodes
                are not updated properly. Similarly, OpenvSwitch ports
                interfaces are not removed when deleting nodes.</para>
              </listitem>

              <listitem>
                <para>As a consequence, when adding a compute node to an
                existing OPNFV deployment, the instances running on the new
                compute node cannot be reached by floating IP. Scale-out and
                scale-in operations are flawed.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>Workaround: The rules can be manually configured, but this
            is not scalable.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Hot-plugging network interfaces does not work in aarch64
        guests</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <itemizedlist>
              <listitem>
                <para>When the user tries to hot-plug a network port to a
                running instance, this fails due to virtio negotiation failure
                between the host and guest. This happens when the VM is using
                a Linux Kernel version prior to 4.10. Port addition or
                deletion is not possible.</para>
              </listitem>

              <listitem>
                <para>This reproduces on aarch64.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>Workaround: The user needs to upgrade the guest Linux Kernel
            to 4.10 or later. In case of port addition, the user also needs to
            manually set the link up and trigger the
            <literal>dhclient</literal> request.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Fuel Healthcheck Configuration tests fail when default
        credentials are used</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <itemizedlist>
              <listitem>
                <para>The Configuration tests from the Fuel Healthcheck fail
                when the OPNFV cluster operates with the default credentials.
                This has no impact on the overall cluster
                functionality.</para>
              </listitem>

              <listitem>
                <para>This is architecture independent.</para>
              </listitem>
            </itemizedlist>
          </listitem>

          <listitem>
            <para>Workaround: In order to make these 3 test cases pass, the
            user needs to:</para>

            <itemizedlist>
              <listitem>
                <para>Change the credentials for the root user on the Fuel
                Master node: after logging on as root on the master node,
                issue command <command>passwd</command> and provide the new
                password.</para>
              </listitem>

              <listitem>
                <para>Change the default credentials for the OpenStack
                cluster: in Fuel Dashboard, for an Environment, change
                Settings|General|OpenStack Access &gt; Password to something
                other than the default.</para>
              </listitem>

              <listitem>
                <para>Change the default credentials for Keystone on the
                master node: in Fuel Dashboard, click on the user avatar and
                select <literal>Change Password</literal>. This should be done
                before deploy or you will need to redeploy to have the changes
                applied.</para>
              </listitem>
            </itemizedlist>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Fuel Healthcheck Stack update test fails</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>The Platform test case number 5 (Update stack) from the Fuel
            Healthcheck sometimes fails. This has no impact on the overal
            cluster functionality.</para>
          </listitem>

          <listitem>
            <para>Workaround: N/A.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Issue #1 with Openstack Resource Agents and Compute Fencing
        functionality</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>In an OPNFV deployment that uses Openstack Resource Agents,
            the neutron-openvswitch-agent is killed by Pacemaker when booting,
            due to Pacemaker misconfiguration.</para>
          </listitem>

          <listitem>
            <para>Workaround:</para>

            <para>Starting the <literal>systemd</literal> service manually
            makes it run successfully. Enea NFV Core 1.0.1 is shipped without
            Openstack Resource Agents, therefore this issue should not affect
            the user.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Issue #2 with Openstack Resource Agents and Compute Fencing
        functionality</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>In an OPNFV deployment that uses Openstack Resource Agents,
            when we configure the <literal>fence_compute</literal> as a
            Pacemaker resource, the Controller nodes start to reboot each
            other endlessly.</para>
          </listitem>

          <listitem>
            <para>Workaround:</para>

            <para>Enea NFV Core 1.0.1 is shipped without Openstack Resource
            Agents, therefore this issue should not affect the user.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Virtual instances are not affected by removing a node from the
        Ceph Storage Cluster</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>Engineering wanted to validate the survival of storage
            systems when a single disk is removed, without causing data loss.
            Without physical access to the test setup, this test is not
            feasible.</para>
          </listitem>

          <listitem>
            <para>Workaround:</para>

            <itemizedlist>
              <listitem>
                <para>The chosen approach was to validate what happens to the
                Ceph cluster, when network connectivity is lost for the
                Storage interface of one of the nodes. No impact was observed
                when running an instance using Ceph for volume storage.</para>
              </listitem>

              <listitem>
                <para><ulink
                url="http://ceph.com/geen-categorie/admin-guide-replacing-a-failed-disk-in-a-ceph-cluster/">Reference
                information</ulink></para>
              </listitem>
            </itemizedlist>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Offline Deploy with Fuel fails at times</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>The Postfix installation and post-install configuration
            sometimes take longer when the Fuel deployment is performed
            without Internet connectivity. The <emphasis
            role="bold">tools</emphasis> Puppet task has a 5 minute completion
            timeout, causing there to not be enough time left for the other
            components of the tools task to be executed.</para>
          </listitem>

          <listitem>
            <para>Workaround:</para>

            <para>Simply press <literal>Deploy changes</literal> again. Since
            by now Postfix is installed, it will skip the installation and
            finish in time.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Volumes fail to attach during the first few seconds of a VM
        booting procedure</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>There is a short period of a few seconds after a VM stated
            the boot procedure when attaching an external volume will result
            in an error to claim the qemu assigned bus in the guest Image
            kernel.</para>

            <para>Disks attached in the first few seconds of the booting
            procedure of a VM, will fail to register in the guest VM.</para>
          </listitem>

          <listitem>
            <para>Workaround:</para>

            <para>Attach volumes to a VM only before the VM is booting or
            after the period of a few seconds has passed since the booting
            procedure started.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Fuel Healthcheck Stack creation with wait condition test,
        fails</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>The platform test case (create stack with wait condition)
            from the Fuel Healthcheck, fails. This has no impact on overall
            cluster functionality.</para>
          </listitem>

          <listitem>
            <para>Workaround: N/A.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>On Mixed Arch Deployment, only the aarch64 TestVM Cirros image
        will be installed by Fuel</para>

        <itemizedlist>
          <listitem>
            <para>Description and Impact:</para>

            <para>Due to the fact that Fuel will only deploy the aarch64
            image, Yardstick, Functest, and certain Health Check tests will
            not work. These test suites are dependent on a single image name
            at a time, and do not know on how to place instances on the
            Compute for images that each require a different arch.</para>

            <para>To have both testVM images, the user must add the x86_64
            image manually.</para>
          </listitem>

          <listitem>
            <para>There is no workaround for the test suites failures.</para>
          </listitem>
        </itemizedlist>
      </listitem>
    </orderedlist>
  </section>

  <section condition="hidden" id="bugs-limitations-doc">
    <title>Documentation</title>

    <itemizedlist spacing="compact">
      <listitem>
        <para><emphasis role="bold">PDF navigation</emphasis>: When using
        links to open other PDFs, or jump to another place in the same PDF,
        jumping back sometimes fails. This has been observed when opening a
        PDF in Adobe Reader, inside a browser with PDF add-on, as well as when
        the browser is configured to open PDF files in an external PDF reader.
        As a workaround, open the HTML version of the
        document.<remark>LXCR-3283</remark></para>
      </listitem>
    </itemizedlist>
  </section>

  <section condition="hidden" id="bugs-limitations-other">
    <title>Miscellaneous</title>

    <itemizedlist spacing="compact">
      <listitem>
        <para></para>

        <remark>list all misc problems here.</remark>
      </listitem>
    </itemizedlist>
  </section>

  <!-- The file with a section below is autocreated by make init

  <xi:include href="jiraissues_generated.xml"
              xmlns:xi="http://www.w3.org/2001/XInclude" /> -->
</chapter>