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>ThunderX integrated NICs cannot be used for SR-IOV</para>

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

            <para>For the moment ENEA NFV Core is missing the support to
            configure ThunderX integrated NICs for deployment. Furthermore,
            ThunderX integrated NICs cannot be used for SR-IOV even if
            configured manually after deployment. This happens because
            ThunderX integrated NICs are themseleves virtual functions and are
            incorrectly handled by libvirt when trying to assign them to a
            virtual machine.</para>

            <para>It is however possible to deploy with SR-IOV over add-on
            interfaces via the PCI-E expansion slots.</para>
          </listitem>

          <listitem>
            <para>Workaround: there is no workaround for this issue. As an
            alternative, the user can configure an external PCI-E NIC for
            SR-IOV.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>ThunderX integrated NICs cannot be used for PCI passthrough with
        direct-physical bound Neutron ports</para>

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

            <itemizedlist>
              <listitem>
                <para>PCI Passthrough using direct-physical bound ports also
                uses the neutron-sriov-agent. Because the interfaces are
                represented as virtual functions, it will be impossible to use
                Neutron ports bound as direct-physical (the Nova driver will
                identify them as type-VF, not type-PF).</para>

                <para>Due to this, it is not possible to claim PCI devices
                using direct-physical bound ports.</para>
              </listitem>
            </itemizedlist>

            <itemizedlist>
              <listitem>
                <para>It is however possible to passthrough any device using
                the PCI alias method, which requries configuring a whitelist
                of PCI devices and assigning an alias which is set as metadata
                in the Nova flavor.</para>
              </listitem>
            </itemizedlist>
          </listitem>

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

            <para>There is no workaround for this issue. As an alternative,
            the user can configure a PCI alias instead.</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>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>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>

      <listitem>
        <para>Removing QoS policies is unreliable</para>

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

            <para>When removing per port bandwidth limiting QoS policies, all
            traffic is suddenly dropped. On the the other hand, when removing
            QoS policies configured at Openstack network level, traffic flows
            as if the rules are still there.</para>
          </listitem>

          <listitem>
            <para>There is no workaround.</para>
          </listitem>
        </itemizedlist>
      </listitem>

      <listitem>
        <para>Enabling Ceph for Glance and Nova ephemeral storage makes the
        deployment fail on aarch64</para>

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

            <para>There are multiple configurable Storage Backends in Fuel
            settings. Enabling Ceph RBD for images (Glance) and Ceph RBD for
            ephemeral volumes (Nova), makes the deployment fail at the CEPH
            Ready Check performed on the primary Controller node. This only
            occurs when using aarch64 nodes; on x86_64, deployment does not
            fail</para>
          </listitem>

          <listitem>
            <para>There is no workaround. The user should not enable these
            options.</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>