Chapter 4. Technical notes

There is currently a known issue where the Swift API does not work and returns a 401 error when multiple Controller nodes are deployed and Ceph is enabled.

A workaround is available at https://access.redhat.com/solutions/6970061. (BZ#2112988)

Before this update, baremetal node introspection failed with an error and did not retry, when the node had a transient lock on it.

With this update, you can perform introspection even when the node has a lock. (BZ#1991657)

You can now migrate the mechanism driver to ML2/OVN from an ML2/OVS deployment that uses the iptables_hybrid firewall driver.

The existing instances keep using the hybrid plug mechanism after the migration, but security groups are implemented in OVN and there are no iptables rules present on the compute nodes. (BZ#2075038)

In an ML2/OVS deployment, Open vSwitch (OVS) does not support offloading OpenFlow rules that have the skb_priority, skb_mark, or output queue fields set. Those fields are needed to provide quality-of-service (QoS) support for virtio ports.

If you set a minimum bandwidth rule for a virtio port, the Neutron Open vSwitch agent marks the traffic of this port with a Packet Mark Field. As a result, this traffic cannot be offloaded, and it affects the traffic in other ports. If you set a bandwidth limit rule, all traffic is marked with the default 0 queue, which means no traffic can be offloaded.

As a workaround, if your environment includes OVS hardware offload ports, disable the packet marking in the nodes that require hardware offloading. After you disable the packet marking, it will not be possible to set rate limiting rules for virtio ports. However, differentiated services code point (DSCP) marking rules will still be available.

In the configuration file, set the disable_packet_marking flag to true. After you edit the configuration file, you must restart the neutron_ovs_agent container. For example:

$ cat `/var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini`
  [ovs]
  disable_packet_marking=True

(BZ#2111015)

In Red Hat OpenStack Platform (RHOSP) 17.0 GA, for NIC-partitioned deployments, you can now pass through virtual functions (VFs) to VMs.

To pass through VFs, in a heat environment file, you must specify the VF product ID, vendor ID, and the physical function (PF) PCI addresses:

NovaPCIPassthrough:
   - product_id: "<VF_product_ID>"
     vendor_id: "<vendor_ID>"
     address: "<PF_PCI_addresses>"
     trusted: "true"

The PF PCI address parameter supports string and dict mapping. You can specify wildcard characters and use regular expressions when specifying one or more addresses.

NovaPCIPassthrough:
   - product_id: "0x7b18"
     vendor_id: "0x8086"
     address: "0000:08:00.*"
     trusted: "true"

(BZ#1913862)

Before this update, the collectd smart plugin required the CAP_SYS_RAWIO capability to work. It was not added by default. With this update, you can add the capability to the collectd container and the smart plugin works. When you use the smart plugin, specify the following parameter in an environment file: CollectdContainerAdditionalCapAdd:

With this update, the Validation Framework provides a configuration file in which you can set parameters for particular use. You can find an example of this file at the root of the code source or in the default location: /etc/validation.cfg.

You can use the default file in /etc/ or use your own file and provide it to the CLI with the argument --config.

When you use a configuration file there is an order for the variables precedence. The following order is the order of variable precedence:

There is currently a known issue in RHOSP 17.0 where the Free Range Router (FRR) container does not start after the host on which it resides is rebooted. This issue is caused by a missing file in the BGP configuration. Workaround: Create the file, /etc/tmpfiles.d/run-frr.conf, and add the following line:

d /run/frr 0750 root root - -

After you make this change, tmpfiles recreates /run/frr after each reboot and the FRR container can start. (BZ#2127965)

Before this update, if an ovn-lb is created (VIP and members) in a LS (neutron network) that has 2 subnets (IPv4 and IPv6), and this LS is connected to a LR, removing the LS from the LR leads to the removal of the ovn-lb from the LS and consequently to remove it from the OVN SB DB as it is not associated to any datapath. When re-adding the LS to the LR (the network and subnets to the router) the ovn-lb will not be properly associated to the LR/LS at OVN level and there will be no connectivity

With this update the IP version is checked so that router ports that belong to other subnets are not considereed and the ovn-lb is not removed from the LS. This results in the ovn-lb having proper connectivity when a subnet is removed from the router. This resolves the issue. (BZ#2135270)

There is currently a known issue that causes tuned kernel configurations to not be applied after initial provisioning.

Workaround: You can use the following custom playbook to ensure that the tuned kernel command line arguments are applied. Save the following playbook as /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-reset-blscfg.yaml on the undercloud node:

- name: Reset BLSCFG of compute node(s) meant for NFV deployments
  hosts: allovercloud
  any_errors_fatal: true
  gather_facts: true

  pre_tasks:
    - name: Wait for provisioned nodes to boot
      wait_for_connection:
        timeout: 600
        delay: 10

  tasks:
    - name: Reset BLSCFG flag in grub file, if it is enabled
      become: true
      lineinfile:
        path: /etc/default/grub
        line: "GRUB_ENABLE_BLSCFG=false"
        regexp: "^GRUB_ENABLE_BLSCFG=.*"
        insertafter: '^GRUB_DISABLE_RECOVERY.*'

Configure the role in the node definition file, overcloud-baremetal-deploy.yaml, to run the cli-overcloud-node-reset-blscfg.yaml playbook before the playbook that sets the kernelargs:

- name: ComputeOvsDpdkSriov
  count: 2
  hostname_format: computeovsdpdksriov-%index%
  defaults:
    networks:
    - network: internal_api
      subnet: internal_api_subnet
    - network: tenant
      subnet: tenant_subnet
    - network: storage
      subnet: storage_subnet
    network_config:
      template: /home/stack/osp17_ref/nic-configs/computeovsdpdksriov.j2
    config_drive:
      cloud_config:
        ssh_pwauth: true
        disable_root: false
        chpasswd:
          list: |-
            root:12345678
        expire: False
  ansible_playbooks:
    - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-reset-blscfg.yaml
    - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
      extra_vars:
        reboot_wait_timeout: 600
        kernel_args: 'default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-11,13-23'
        tuned_profile: 'cpu-partitioning'
        tuned_isolated_cores: '1-11,13-23'
    - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-openvswitch-dpdk.yaml
      extra_vars:
        memory_channels: '4'
        lcore: '0,12'
        pmd: '1,13,2,14,3,15'
        socket_mem: '4096'
        disable_emc: false
        enable_tso: false
        revalidator: ''
        handler: ''
        pmd_auto_lb: false
        pmd_load_threshold: ''
        pmd_improvement_threshold: ''
        pmd_rebal_interval: ''
        nova_postcopy: true

(BZ#2107896)