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

Wrong PrimarySubnet in OpenstackProviderSpec when using Failure Domains

    XMLWordPrintable

Details

    • +
    • 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

    Description

      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.

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. OCPBUGS-10570 Wrong PrimarySubnet in OpenstackProviderSpec when using Failure Domains

          • Normal - To be worked after urgent and high priorities are resolved. This term is chosen when the severity of an issue is relatively close to the level of effort to fix it. The existence of an easily implemented workaround can also lead to this priority level instead of a higher priority.
          • Closed
          is blocked by

          Bug - A problem that impairs or prevents the functions of the product. OCPBUGS-10570 Wrong PrimarySubnet in OpenstackProviderSpec when using Failure Domains

          • Normal - To be worked after urgent and high priorities are resolved. This term is chosen when the severity of an issue is relatively close to the level of effort to fix it. The existence of an easily implemented workaround can also lead to this priority level instead of a higher priority.
          • Closed
          links to

          GitHub openshift/installer#7008: [release-4.13] OCPBUGS-10658: openstack: No master primarySubnet control-plane if portTarget is set

          Activity

            People

              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

              Dates

                Created:
                Updated:
                Resolved: