-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework defaulting of secrets #211
Open
jpodivin
wants to merge
1
commit into
openstack-k8s-operators:main
Choose a base branch
from
jpodivin:defaults
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still have this logic somehow represented in the reworked version? If I understand correctly, we don't want to create a
networkDataSecret
if apreProvNetworkData
secret has been set for the host [1]. @rabi can you keep me honest here? :)[1]
openstack-baremetal-operator/pkg/openstackbaremetalset/baremetalhost.go
Lines 186 to 189 in 615a9be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've dropped that because nobody could really tell me why. If there is a good reason for it, the conditional can get back in. Along with error to be raised in case it fails obviously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed this a bit on Slack last friday, Rabi also opened a Jira to discuss.
OCP's capabilities to configure the provisioning network is very limited, it does not support/cannot be configured to use the provisioning network when the nodes are not connected L2 to the provisioning network. OCP's answer to this is to use the "External" network instead. Since we have the RHOSO isolated networks configured on the OCP nodes, we quickly end up with asymmetric routing to consider.
One way to get around the asymmetric routing would be to use different network configuration in preProvisioning - i.e the ramdisk uses 192.168.25.0/24, 192.168.25.0/24 - a range that OCP nodes use the default route for, to ensure incoming and return traffic is all on the OCP "External" interface.
I imagined that we would have customers configure the
PreprovisioningNetworkDataName
for their BMO's and we would still set NetworkData via template. (What @jpodivin is doing in this patch if I get it right?).However Rabi brought the feedback that the field asked for
preprovisioningNetworkData
to propagate tonetworkData
- i.e not using template. Because that is what OCP/Metal3 does. I think this argument is valid, it will be confusing for users with experience using OCP Metal3 if we behave differently.I reconsidered my position once I got Rabi (and the fields) arguments. We should keep behavior aligned with OCP/Metal3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There still seems to be some discussion to be had about the desire behavior. So for now the behavior will remain the same. I've restored conditional on
PreprovisioningNetworkDataName
. Now the PR is purely housekeeping effort.When there is a decision on what should take primacy, it's just a question of minor adjustment.