Bug 1833483: Revert "baremetal: send full ignition to masters" #3589
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was merged in openshift#3276 but had the side-effect of breaking an interface some users were already reliant on, where additional config is added to the pointer ignition output via `create ignition-configs` Downstream bz https://bugzilla.redhat.com/show_bug.cgi?id=1833483 reported this issue, and we've taken the decision to revert this to resolve that interface regression, and look at other ways to satisfy the requirements that led to openshift#3276 This reverts commit f67d61a.
openshift-ci-robot
added
bugzilla/severity-unspecified
|
@hardys: This pull request references Bugzilla bug 1833483, which is invalid:
Comment In response to this:
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/test-infra repository. |
|
/bugzilla refresh |
openshift-ci-robot
added
the
bugzilla/valid-bug
|
@hardys: This pull request references Bugzilla bug 1833483, which is valid. 3 validation(s) were run on this bug
In response to this:
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/test-infra repository. |
openshift-ci-robot
removed
the
bugzilla/invalid-bug
|
/test e2e-metal-ipi |
|
/test e2e-metal-ipi There's some kind of on-going issue with Packet today. SSH isn't coming up. :-\ |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya 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:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
e2e-metal-ipi succeeded, it hit the must-gather flake at the end we're still investigating. /lgtm |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
@hardys: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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/test-infra repository. I understand the commands that are listed here. |
|
@hardys: All pull requests linked via external trackers have merged: openshift/installer#3589. Bugzilla bug 1833483 has been moved to the MODIFIED state. In response to this:
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/test-infra repository. |
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 24, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 24, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 24, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 24, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 25, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 27, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Nov 27, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Dec 1, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Dec 2, 2020
This restores the work which was previously done via openshift#3276 but then reverted via openshift#3589 due to breaking users who customized the pointer ignition config in IPI deployments. A solution to that has been proposed via openshift#4413 - see openshift/enhancements#540 for more details. Note that some additional changes beyond the initial implementation were required due to the MCO now supporting multiple ignition versions, thus this depends on openshift-metal3/terraform-provider-ironic#46 Co-Authored-By: Steven Hardy <[email protected]>
hardys
pushed a commit
to hardys/installer
that referenced
this pull request
Dec 2, 2020
This restores the work which was previously done via openshift#3276 but then reverted via openshift#3589 due to breaking users who customized the pointer ignition config in IPI deployments. A solution to that has been proposed via openshift#4413 - see openshift/enhancements#540 for more details. Note that some additional changes beyond the initial implementation were required due to the MCO now supporting multiple ignition versions, thus this depends on openshift-metal3/terraform-provider-ironic#46 Co-Authored-By: Steven Hardy <[email protected]>
michaelgugino
pushed a commit
to mgugino-upstream-stage/installer
that referenced
this pull request
Dec 4, 2020
In the case where an IPI user customizes the pointer config, this config is only persisted via the user-data secret, which was an issue when moving to an MCO templated pointer config: openshift#4228 It was also a problem for attempts for IPI baremetal to consume the MCO rendered config directly, with the aim of enabling network configuration via MachineConfig: openshift#3589 With this new approach, we detect the case where a change has been made to the pointer config by the user, and in that case it is stored via a MachineConfig manifest, such that any customizations are reflected in the MCO rendered config. Implements: openshift/enhancements#540 Co-Authored-By: Steven Hardy <[email protected]>
michaelgugino
pushed a commit
to mgugino-upstream-stage/installer
that referenced
this pull request
Dec 4, 2020
This restores the work which was previously done via openshift#3276 but then reverted via openshift#3589 due to breaking users who customized the pointer ignition config in IPI deployments. A solution to that has been proposed via openshift#4413 - see openshift/enhancements#540 for more details. Note that some additional changes beyond the initial implementation were required due to the MCO now supporting multiple ignition versions, thus this depends on openshift-metal3/terraform-provider-ironic#46 Co-Authored-By: Steven Hardy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was merged in #3276
but had the side-effect of breaking an interface some users were
already reliant on, where additional config is added to the
pointer ignition output via
create ignition-configsDownstream bz https://bugzilla.redhat.com/show_bug.cgi?id=1833483
reported this issue, and we've taken the decision to revert this
to resolve that interface regression, and look at other ways to
satisfy the requirements that led to #3276
This reverts commit f67d61a.