Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-1951

noAllowedAddressPairs set to true causes all the ports to be added without the allowed address pairs

    XMLWordPrintable

Details

    • ?
    • Moderate
    • ShiftStack Sprint 225, ShiftStack Sprint 226
    • 2
    • False
    • Hide

      None

      Show
      None
    • Hide
      Cause: noAllowedAddressPairs can be set on a subnet. However, the setting applied to all subnets in the same network.
      Consequence: It is not possible to set noAllowedAddressPairs to False on a subnet that sits in the same network of a subnet for which noAllowedAddressPairs is set to true.
      Fix: cluster-api-provider-openstack has been amended to only apply the setting to the filtered subnet
      Result: noAllowedAdderssPairs now applies to the corresponding subnet only.
      Show
      Cause: noAllowedAddressPairs can be set on a subnet. However, the setting applied to all subnets in the same network. Consequence: It is not possible to set noAllowedAddressPairs to False on a subnet that sits in the same network of a subnet for which noAllowedAddressPairs is set to true. Fix: cluster-api-provider-openstack has been amended to only apply the setting to the filtered subnet Result: noAllowedAdderssPairs now applies to the corresponding subnet only.

    Description

      This is a clone of issue OCPBUGS-1890. The following is the description of the original issue:

      This is a clone of issue OCPBUGS-1765. The following is the description of the original issue:

      Description of problem:

      If a customer creates a machine with a networks section like this
      
      networks:
      - filter: {}
        noAllowedAddressPairs: false
        subnets:
        - filter: {}
          uuid: primary-subnet-uuid
      - filter: {}
        noAllowedAddressPairs: true
        subnets:
        - filter: {}
          uuid: other-subnet-uuid
      primarySubnet: primary-subnet-uuid
      
      Then all the ports are created without the allowed address pairs.
      
      Doing some research in the source code, I have found that:
      - For each entry on the networks: section, networks are filtered as per its filter: section[1]
      - Then, if the subnets: section of the network entry is not empty, for each of the network IDs found above[2], 2 things are done that are relevant for this situatoin:
        - The net ID is saved on a netsWithoutAllowedAddressPairs[3]. That map is later checked while creating any port[4].
        - For each subnet entry that matches the network ID, a port is created[5].
      
      So, the problematic behavior happens due to the following:
      
      - Both entries in the networks array have empty filters. This means that both entries selected all the neutron networks.
      - This configuration results in one port per subnet as expected because, in the later traversal of the subnets array of each entry[5], it is filtering by subnet and creating a single port as expected.
      - However, the entry with "noAllowedAddressPairs: true" is selecting all the neutron networks, so it adds all of them to the netsWithoutAllowedAddressPairs map[3], regardless of the subnets filtering.
      - As all the networks are in noAllowedAddressPairs: true array, all the ports created for the VM have their allowed address pairs removed[4].
      
      Why do we consider this behavior undesired?
      
      I understand that, if we create a port for a network that has no allowed pairs, we create all the other ports in the same networks without the pairs. However, it is surprising that a port in a network is removed the allowed address pairs due to a setting in an entry that yielded no port on that network. In other words, one would expect that the same subnet filtering that happens on each network entry in what regards yielding ports for the VM would also work for the noAllowedPairs parameter.
      
      

      Version-Release number of selected component (if applicable):

      4.10.30
      

      How reproducible:

      Always
      

      Steps to Reproduce:

      1. Create a machineset like in the description
      2.
      3.
      

      Actual results:

      All ports have no address pairs
      

      Expected results:

      Only the port on the secondary subnet has no address pairs.
      

      Additional info:

      A simple workaround would be to just fill the filter so that a single network is selected for each network entry.
      
      References:
      [1] - https://github.com/openshift/cluster-api-provider-openstack/blob/f6b51710d4f395ded401347589447f5f41dd5c4c/pkg/cloud/openstack/clients/machineservice.go#L576
      [2] - https://github.com/openshift/cluster-api-provider-openstack/blob/f6b51710d4f395ded401347589447f5f41dd5c4c/pkg/cloud/openstack/clients/machineservice.go#L580
      [3] - https://github.com/openshift/cluster-api-provider-openstack/blob/f6b51710d4f395ded401347589447f5f41dd5c4c/pkg/cloud/openstack/clients/machineservice.go#L581-L583
      [4] - https://github.com/openshift/cluster-api-provider-openstack/blob/f6b51710d4f395ded401347589447f5f41dd5c4c/pkg/cloud/openstack/clients/machineservice.go#L658-L660
      [5] - https://github.com/openshift/cluster-api-provider-openstack/blob/f6b51710d4f395ded401347589447f5f41dd5c4c/pkg/cloud/openstack/clients/machineservice.go#L610-L625
      

      Attachments

        Issue Links

          Activity

            People

              pprinett@redhat.com Pierre Prinetti
              openshift-crt-jira-prow OpenShift Prow Bot
              Ramón Lobillo Ramón Lobillo
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: