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

Wrong PrimarySubnet in OpenstackProviderSpec when using Failure Domains

XMLWordPrintable

    • +
    • No
    • ShiftStack Sprint 233, ShiftStack Sprint 234, ShiftStack Sprint 235
    • 3
    • False
    • Hide

      None

      Show
      None
    • Hide
      Previously, an issue exists with the code base that sets `Machine.PrimaryNetwork` based on the`controlPlane.platform.openstack.failureDomain` field in the `install-config.yaml` file. Specifically, when you set a `control-plane` port in a `failureDomain` Technology Preview component in your installation configuration file, the installation program continues to use a default network subnet, or `platform.openstack.machinesSubnet` if present, when the program should use `controlPlane.platform.openstack.failureDomain[].portTarget[id==control-plane]`. This issue impacts {product-title} that runs with Kuryr from identifying the port on a {rh-openstack-first} subnet that control plane machines use for communicating between them. Now, when you set `control-plane` for `portTarget` in the `failureDomain` Technology Preview component, the installation program sets the port's information in the `Machine.PrimaryNetwork` field, so that your {product-title} cluster can succesfully run with Kuryr. (link:https://issues.redhat.com/browse/OCPBUGS-10658[*OCPBUGS-10658*])
      Show
      Previously, an issue exists with the code base that sets `Machine.PrimaryNetwork` based on the`controlPlane.platform.openstack.failureDomain` field in the `install-config.yaml` file. Specifically, when you set a `control-plane` port in a `failureDomain` Technology Preview component in your installation configuration file, the installation program continues to use a default network subnet, or `platform.openstack.machinesSubnet` if present, when the program should use `controlPlane.platform.openstack.failureDomain[].portTarget[id==control-plane]`. This issue impacts {product-title} that runs with Kuryr from identifying the port on a {rh-openstack-first} subnet that control plane machines use for communicating between them. Now, when you set `control-plane` for `portTarget` in the `failureDomain` Technology Preview component, the installation program sets the port's information in the `Machine.PrimaryNetwork` field, so that your {product-title} cluster can succesfully run with Kuryr. (link: https://issues.redhat.com/browse/OCPBUGS-10658 [* OCPBUGS-10658 *])
    • Bug Fix
    • Done

      This is a clone of issue OCPBUGS-10570. The following is the description of the original issue:
      —
      What happens:

      When deploying OpenShift 4.13 with Failure Domains, the PrimarySubnet in the ProviderSpec of the Machine is  set to the MachinesSubnet set in install-config.yaml.

       

      What is expected:

      Machines in failure domains with a control-plane port target should not use the MachinesSubnet as a primary subnet in the provider spec. it should be the ID of the subnet that is actually used for the control plane on that domain.

       

      How to reproduce:

      install-config.yaml:

      apiVersion: v1
baseDomain: shiftstack.com
compute:
- name: worker
  platform:
    openstack:
      type: m1.xlarge
  replicas: 1
controlPlane:
  name: master
  platform:
    openstack:
      type: m1.xlarge
      failureDomains:
      - portTargets:
        - id: control-plane
          network:
            id: fb6f8fea-5063-4053-81b3-6628125ed598
          fixedIPs:
          - subnet:
              id: b02175dd-95c6-4025-8ff3-6cf6797e5f86
        computeAvailabilityZone: nova-az1
        storageAvailabilityZone: cinder-az1
      - portTargets:
        - id: control-plane
          network:
            id: 9a5452a8-41d9-474c-813f-59b6c34194b6
          fixedIPs:
          - subnet:
              id: 5fe5b54a-217c-439d-b8eb-441a03f7636d
        computeAvailabilityZone: nova-az1
        storageAvailabilityZone: cinder-az1
      - portTargets:
        - id: control-plane
          network:
            id: 3ed980a6-6f8e-42d3-8500-15f18998c434
          fixedIPs:
          - subnet:
              id: a7d57db6-f896-475f-bdca-c3464933ec02
        computeAvailabilityZone: nova-az1
        storageAvailabilityZone: cinder-az1
  replicas: 3
metadata:
  name: mycluster
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 192.168.10.0/24
  - cidr: 192.168.20.0/24
  - cidr: 192.168.30.0/24
  - cidr: 192.168.72.0/24
  - cidr: 192.168.100.0/24
platform:
  openstack:
    cloud: foch_openshift
    machinesSubnet: b02175dd-95c6-4025-8ff3-6cf6797e5f86
    apiVIPs:
    - 192.168.100.240
    ingressVIPs:
    - 192.168.100.250
    loadBalancer:
      type: UserManaged
featureSet: TechPreviewNoUpgrade

      Machine spec:

        Provider Spec:
    Value:
      API Version:  machine.openshift.io/v1alpha1
      Cloud Name:   openstack
      Clouds Secret:
        Name:       openstack-cloud-credentials
        Namespace:  openshift-machine-api
      Flavor:       m1.xlarge
      Image:        foch-bgp-2fnjz-rhcos
      Kind:         OpenstackProviderSpec
      Metadata:
        Creation Timestamp:  <nil>
      Networks:
        Filter:
        Subnets:
          Filter:
            Id:        5fe5b54a-217c-439d-b8eb-441a03f7636d
        Uuid:          9a5452a8-41d9-474c-813f-59b6c34194b6
      Primary Subnet:  b02175dd-95c6-4025-8ff3-6cf6797e5f86
      Security Groups:
        Filter:
        Name:  foch-bgp-2fnjz-master
        Filter:
        Uuid:             1b142123-c085-4e14-b03a-cdf5ef028d91
      Server Group Name:  foch-bgp-2fnjz-master
      Server Metadata:
        Name:                  foch-bgp-2fnjz-master
        Openshift Cluster ID:  foch-bgp-2fnjz
      Tags:
        openshiftClusterID=foch-bgp-2fnjz
      Trunk:  true
      User Data Secret:
        Name:  master-user-data
Status:
  Addresses:
    Address:  192.168.20.20
    Type:     InternalIP
    Address:  foch-bgp-2fnjz-master-1
    Type:     Hostname
    Address:  foch-bgp-2fnjz-master-1
    Type:     InternalDNS

      The machine is connected to the right subnet, but has a wrong PrimarySubnet configured.

              pprinett@redhat.com Pierre Prinetti
              openshift-crt-jira-prow OpenShift Prow Bot
              Itshak Brown Itshak Brown
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: