Skip to content

Conversation

@stbenjam
Copy link
Member

@stbenjam stbenjam commented Jun 23, 2020

This enhancement describes what's required to make the provisioning
network optional. This enhancement adds a new option to the installer (provisioningNetwork) that takes the values managed, unmanaged, and disabled. The former provisioningDHCPExternal option is deprecated.

This enhancement describes what's required to make the provisioning
network optional.
@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 23, 2020
the external network that are used for the provisioning services.

The same field will be added to the Provisioning CRD, with the
provisioningDHCPExternal field removed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the existing field will take a couple of releases. In the mean time, we will need to declare which field takes precedence over the other and support not having the ProvisioningNetwork option set at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the benefit of removing it? Is it worth breaking backwards compatibility instead of just dropping it from docs?

Can you also add a reference to the current definition of this CRD?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm ok, I'll update this section. We could leave it around forever I suppose, but undocumented.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the Provisioning CRD was added purely to enable the installer to pass data to the MAO ref openshift/machine-api-operator#460 - we had a bunch of discussion on openshift/api#540 before that, and one of the reasons it wasn't added to openshift/api was avoid publishing any "external" interface.

So IMO it's probably fine to deprecate then later remove the existing option, given that it's highly likely that the only user of this interface is the installer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK thanks for clarifying

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I clarified this, please have a look to see if it's clear.

@dhellmann
Copy link
Contributor

/lgtm

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhellmann, stbenjam

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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 openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 24, 2020
@openshift-merge-robot openshift-merge-robot merged commit 8ae65e0 into openshift:master Jun 24, 2020
@stbenjam stbenjam deleted the optional branch June 24, 2020 20:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants