MGMT-19500: Enable the installation of a baremetal cluster with a user-managed load balancer, where nodes are in the same subnet, and the load balancer IP is within the subnet

[danmanor]

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
  "load_balancer": {
    "type": "user-managed"
  }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
  baremetal:
    loadBalancer:
      type: UserManaged
    apiVIPs:
    - <load_balancer_ip>
    ingressVIPs:
    - <load_balancer_ip>

Note that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#nw-osp-configuring-external-load-balancer_ipi-install-installation-workflow

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal platform. a follow-up PR should implement this logic for vsphere as well.

Notes

• This PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danmanor

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [danmanor]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an external load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 ...
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note that when using an external load balancer the VIPs will not be
used, but we are still requiring them, and using them to calculate the
machine CIDR. Insted we should validate that no VIPs are given, and we
should calculate the machine CIDR in some other way. That is not part of
this patch.

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an external load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note that when using an external load balancer the VIPs will not be
used, but we are still requiring them, and using them to calculate the
machine CIDR. Insted we should validate that no VIPs are given, and we
should calculate the machine CIDR in some other way. That is not part of
this patch.

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note - that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

Note - that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged
   apiVIPs:
   - <api_ip> 2
   ingressVIPs:
   - <ingress_ip> 3

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note - that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

Note - that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#ipi-install-establishing-communication-between-subnets_ipi-install-installation-workflow

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged
   apiVIPs:
   - <api_ip>
   ingressVIPs:
   - <ingress_ip>

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note - that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

Note - that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#ipi-install-establishing-communication-between-subnets_ipi-install-installation-workflow

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged
   apiVIPs:
   - <load_balancer_ip>
   ingressVIPs:
   - <load_balancer_ip>

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note - that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

Note - that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#ipi-install-establishing-communication-between-subnets_ipi-install-installation-workflow

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged
   apiVIPs:
   - <load_balancer_ip>
   ingressVIPs:
   - <load_balancer_ip>

Note - that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note - that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#ipi-install-establishing-communication-between-subnets_ipi-install-installation-workflow

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged
   apiVIPs:
   - <load_balancer_ip>
   ingressVIPs:
   - <load_balancer_ip>

Note that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#ipi-install-establishing-communication-between-subnets_ipi-install-installation-workflow

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@danmanor: This pull request references MGMT-19500 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set.

In response to this:

This patch adds support for using an user managed load balancer. It will only be available for OpenShift 4.16 or newer. To enable it the user will have to use the new load_balancer.type field of the cluster type, for example:

{
 "load_balancer": {
   "type": "user-managed"
 }
}

To preserve backwards compatibility this will be optional, and the
default value will be cluster-managed.

When the value is user-managed the following will be added to the
generated install-config.yaml file:

platform:
 baremetal:
   loadBalancer:
     type: UserManaged
   apiVIPs:
   - <load_balancer_ip>
   ingressVIPs:
   - <load_balancer_ip>

Note that when using an user managed load balancer the VIPs will be
used to specify the load balancer IP (not actually virtual).

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#nw-osp-configuring-external-load-balancer_ipi-install-installation-workflow

The database will be automatically migrated so that for existing
clusters the value of the load_balancer_type column will automatically
be set to cluster-managed.

This patch adds this support only for the baremetal and vsphere
platforms.

Note that this PR still require all hosts to be on the same subnet (same broadcast range). There is going to be a follow-up PR to enable hosts in different subnets as well.

More info can be found here - https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/deploying_installer-provisioned_clusters_on_bare_metal/ipi-install-installation-workflow#ipi-install-establishing-communication-between-subnets_ipi-install-installation-workflow

List all the issues related to this PR

• New Feature
• Enhancement
• Bug fix
• Tests
• Documentation
• CI/CD

What environments does this code impact?

• Automation (CI, tools, etc)
• Cloud
• Operator Managed Deployments
• None

How was this code tested?

• assisted-test-infra environment
• dev-scripts environment
• Reviewer's test appreciated
• Waiting for CI to do a full test run
• Manual (Elaborate on how it was tested)
• No tests needed

Checklist

• Title and description added to both, commit and PR.
• Relevant issues have been associated (see CONTRIBUTING guide)
• This change does not require a documentation update (docstring, docs, README, etc)
• Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

• Are the title and description (in both PR and commit) meaningful and clear?
• Is there a bug required (and linked) for this change?
• Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[danmanor]

/hold

[codecov]

Codecov Report

Attention: Patch coverage is 88.80597% with 15 lines in your changes missing coverage. Please review.

Project coverage is 67.60%. Comparing base (744bc1f) to head (60da7b3).
Report is 13 commits behind head on master.

Files with missing lines	Patch %	Lines
internal/cluster/validations/validations.go	0.00%	6 Missing ⚠️
internal/bminventory/inventory.go	90.90%	1 Missing and 2 partials ⚠️
...oller/controllers/clusterdeployments_controller.go	84.61%	1 Missing and 1 partial ⚠️
internal/featuresupport/features_networking.go	93.33%	1 Missing and 1 partial ⚠️
internal/network/utils.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7096      +/-   ##
==========================================
- Coverage   67.86%   67.60%   -0.27%     
==========================================
  Files         291      296       +5     
  Lines       39831    40202     +371     
==========================================
+ Hits        27030    27177     +147     
- Misses      10361    10580     +219     
- Partials     2440     2445       +5     

Files with missing lines	Coverage Δ
internal/cluster/validator.go	95.46% <100.00%> (+0.11%)	⬆️
internal/common/common.go	28.57% <ø> (ø)
internal/featuresupport/feature_support_level.go	96.49% <ø> (ø)
internal/featuresupport/features_misc.go	88.26% <ø> (ø)
internal/featuresupport/features_platforms.go	93.15% <100.00%> (+0.72%)	⬆️
internal/network/machine_network_cidr.go	61.35% <100.00%> (+0.76%)	⬆️
internal/provider/baremetal/installConfig.go	53.84% <100.00%> (+10.98%)	⬆️
...oller/controllers/clusterdeployments_controller.go	72.89% <84.61%> (+0.09%)	⬆️
internal/featuresupport/features_networking.go	87.07% <93.33%> (+1.66%)	⬆️
internal/network/utils.go	45.94% <0.00%> (-0.32%)	⬇️
... and 2 more

... and 11 files with indirect coverage changes

[paul-maidment]

Is this only to be used in "User Managed Networking" mode or does this somehow work in "cluster managed" networking, with the only exception being load balancer config?

[danmanor]

Yes

[paul-maidment]

I assume that's a "yes" to "This only works for UMN"

Do we verify that the networking is UMN when allowing this to be set?

[danmanor]

Oh no I meant this work in "cluster managed" networking, with the only exception being load balancer config

[danmanor]

Sorry

[avishayt]

What is the effect of user-managed networking + user-managed LB?

[danmanor]

I blocked it

[danmanor]

It is simpler to manage this feature as part of cluster-managed-networking rather then part of user-managed-networking

[paul-maidment]

The title of this issue contains "....with user managed load balancer and nodes are part of the same subnet".
I notice that the validation code skips any kind of validation of this when the LB is user managed.

Is there a validation performed before the installation starts to ensure that the user LB is reachable?

[eranco74]

/lgtm

[danmanor]

/override ci/prow/edge-e2e-oci-assisted-4-18 ci/prow/edge-e2e-oci-assisted-4-14

[openshift-ci]

@danmanor: Overrode contexts on behalf of danmanor: ci/prow/edge-e2e-oci-assisted-4-14, ci/prow/edge-e2e-oci-assisted-4-18

In response to this:

/override ci/prow/edge-e2e-oci-assisted-4-18 ci/prow/edge-e2e-oci-assisted-4-14

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[danmanor]

/override ci/prow/edge-e2e-oci-assisted-4-14

[openshift-ci]

@danmanor: Overrode contexts on behalf of danmanor: ci/prow/edge-e2e-oci-assisted-4-14

In response to this:

/override ci/prow/edge-e2e-oci-assisted-4-14

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[eranco74]

Currently just baremetal (no vSphere)

[eranco74]

Consider renameing to shouldVerifyIfVipIsFree, current name is too similar to VerifyVipFree

[paul-maidment]

Agree

[danmanor]

/test edge-e2e-metal-assisted-kube-api-umlb-4-18 edge-e2e-metal-assisted-umlb-4-18

[danmanor]

/override ci/prow/edge-e2e-ai-operator-disconnected-capi ci/prow/edge-e2e-nutanix-assisted-4-18 ci/prow/okd-scos-e2e-aws-ovn

[danmanor]

/hold

[openshift-ci]

@danmanor: Overrode contexts on behalf of danmanor: ci/prow/edge-e2e-ai-operator-disconnected-capi, ci/prow/edge-e2e-nutanix-assisted-4-18, ci/prow/okd-scos-e2e-aws-ovn

In response to this:

/override ci/prow/edge-e2e-ai-operator-disconnected-capi ci/prow/edge-e2e-nutanix-assisted-4-18 ci/prow/okd-scos-e2e-aws-ovn

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[danmanor]

/override ci/prow/edge-e2e-nutanix-assisted-4-14

[openshift-ci]

@danmanor: Overrode contexts on behalf of danmanor: ci/prow/edge-e2e-nutanix-assisted-4-14

In response to this:

/override ci/prow/edge-e2e-nutanix-assisted-4-14

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[paul-maidment]

/test edge-e2e-ai-operator-ztp

[paul-maidment]

/test edge-e2e-metal-assisted-kube-api-umlb-4-18

[paul-maidment]

Assuming that the user accepts responsibility for setting up their load balancer and that we do not need to verify the provided VIP then I think this works fine.

Do E2E tests currently make use of the API VIP in any way, if so then would it be worth the extra step of setting up a "user defined" load balancer for the sake of making sure everything still works when the VIP is not the one we have already set up in the test?

[danmanor]

@paul-maidment I created two new tests that test this exact scenario -

• edge-e2e-metal-assisted-kube-api-umlb-4-18
• edge-e2e-metal-assisted-umlb-4-18

They both passed, there is a small patch I need to add to kube-api-umlb-4-18 which currently fails the conformance tests (after the installation)

[danmanor]

/unhold

[danmanor]

/test edge-e2e-metal-assisted-kube-api-umlb-4-18

[paul-maidment]

/lgtm

[danmanor]

/test edge-subsystem-kubeapi-aws

[openshift-ci]

@danmanor: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/edge-e2e-metal-assisted-kube-api-umlb-4-18	60da7b3	link	false	/test edge-e2e-metal-assisted-kube-api-umlb-4-18

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-agent-installer-api-server
This PR has been included in build ose-agent-installer-api-server-container-v4.19.0-202412291341.p0.g6cdfd59.assembly.stream.el9.
All builds following this will include this PR.