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

The subnet/instance information of control plane node does not match the actual info AWS console

XMLWordPrintable

    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • Important
    • None
    • Proposed
    • None
    • In Progress
    • Bug Fix
    • Hide
      * Previously, when installing into an existing virtual private cloud (VPC) on {aws-first}, a potential mismatch could occur in the subnet information in the {aws-short} Availability Zone between the machine set custom resources for control plane nodes and their corresponding {aws-short} EC2 instances. As a consequence, where the control plane nodes were spread across three Availability Zones and one was recreated the discrepancy could result in an unbalanced control plane as two nodes occurred within the same Availability Zone. With this release, it is ensured that the subnet Availability Zone information in the machine set custom resources and in the EC2 instances match and the issue is resolved. (link:https://issues.redhat.com/browse/CPBUGS-57293[OCPBUGS-57293])
      Show
      * Previously, when installing into an existing virtual private cloud (VPC) on {aws-first}, a potential mismatch could occur in the subnet information in the {aws-short} Availability Zone between the machine set custom resources for control plane nodes and their corresponding {aws-short} EC2 instances. As a consequence, where the control plane nodes were spread across three Availability Zones and one was recreated the discrepancy could result in an unbalanced control plane as two nodes occurred within the same Availability Zone. With this release, it is ensured that the subnet Availability Zone information in the machine set custom resources and in the EC2 instances match and the issue is resolved. (link: https://issues.redhat.com/browse/CPBUGS-57293 [ OCPBUGS-57293 ])
    • None
    • None
    • None
    • None

      This is a clone of issue OCPBUGS-57220. The following is the description of the original issue:
      —
      This is a clone of issue OCPBUGS-55492. The following is the description of the original issue:
      —
      Description of problem:

      Create a Shared-VPC cluster, `oc get machine` info shows the master-0's subnet is subnet-05923e64522027287, but the instance (i-076fb2ae38f7573a5) is actually in another subnet (subnet-022e9a1b5b09c4cd0).

No such issues in worker nodes.

--------- master / yunjiang-s16-nctjj-master-0
** From Cluster cluster
Name:	yunjiang-s16-nctjj-master-0
Role:	master
Subnet:	subnet-05923e64522027287
Placement AZ:	us-east-1c
Provider ID:	aws:///us-east-1d/i-076fb2ae38f7573a5
Label machine.openshift.io/zone:	us-east-1d
Instance ID:	i-076fb2ae38f7573a5

** From AWS VPC: subnet-05923e64522027287
Subnet AZ:	us-east-1c
Subnet AZ ID:	use1-az2

** From AWS EC2: i-076fb2ae38f7573a5
Subnet:	subnet-022e9a1b5b09c4cd0
Placement AZ:	us-east-1d

--------- master / yunjiang-s16-nctjj-master-1
** From Cluster cluster
Name:	yunjiang-s16-nctjj-master-1
Role:	master
Subnet:	subnet-022e9a1b5b09c4cd0
Placement AZ:	us-east-1d
Provider ID:	aws:///us-east-1a/i-08a970c88a2c886e6
Label machine.openshift.io/zone:	us-east-1a
Instance ID:	i-08a970c88a2c886e6

** From AWS VPC: subnet-022e9a1b5b09c4cd0
Subnet AZ:	us-east-1d
Subnet AZ ID:	use1-az4

** From AWS EC2: i-08a970c88a2c886e6
Subnet:	subnet-033ab40a49159af26
Placement AZ:	us-east-1a

--------- master / yunjiang-s16-nctjj-master-2
** From Cluster cluster
Name:	yunjiang-s16-nctjj-master-2
Role:	master
Subnet:	subnet-033ab40a49159af26
Placement AZ:	us-east-1a
Provider ID:	aws:///us-east-1c/i-044f5144d45cf131a
Label machine.openshift.io/zone:	us-east-1c
Instance ID:	i-044f5144d45cf131a

** From AWS VPC: subnet-033ab40a49159af26
Subnet AZ:	us-east-1a
Subnet AZ ID:	use1-az6

** From AWS EC2: i-044f5144d45cf131a
Subnet:	subnet-05923e64522027287
Placement AZ:	us-east-1c

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

      likely all CAPI version of installer, I tested 4.16.0-0.nightly-2025-04-28-030235 and
4.18.0-0.nightly-2025-04-26-080749

      How reproducible:

      Always

      Steps to Reproduce:

          1. Create Shared-VPC cluster

      Actual results:

      As described

      Expected results:

      Additional info:

      Correct the subnet/instance info.

              rh-ee-thvo Thuan Vo
              openshift-crt-jira-prow OpenShift Prow Bot
              None
              None
              Yunfei Jiang Yunfei Jiang
              None
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: