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

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


    • ?
    • Moderate
    • ShiftStack Sprint 225
    • 1
    • False
    • Hide



      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
      - filter: {}
        noAllowedAddressPairs: false
        - filter: {}
          uuid: primary-subnet-uuid
      - filter: {}
        noAllowedAddressPairs: true
        - 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):


      How reproducible:


      Steps to Reproduce:

      1. Create a machineset like in the description

      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.
      [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

            pprinett@redhat.com Pierre Prinetti
            openshift-crt-jira-prow OpenShift Prow Bot
            Jon Uriarte Jon Uriarte
            0 Vote for this issue
            8 Start watching this issue