-
Notifications
You must be signed in to change notification settings - Fork 1.5k
baremetal: Disable network interfaces and BMH validations when needed #3794
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
Closed
Closed
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 hidden or 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 file contains hidden or 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 file contains hidden or 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.
Did you look into alternatives that avoid this new boolean?
I think the main issue here is that the validations happen on
create ignition-configs- I wonder if we can either ensure they only happen oncreate clusteror alternatively use some special value toLibvirtURIthat indicates libvirt related validations should be disabled?/cc @stbenjam any thoughts on the best interface here?
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 agree -- adding anything to the platform is a last resort. Changing when the validations run may be the best solution.
If we need to run some validations before create ignition to make sure we don't make bad ignition configs, I'd prefer to opt for some indication we're doing an assisted install. Disabling validations is probably not the only conditional thing we'll need to do for it.
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.
This is another example of why I think "assisted-baremetal" is a different platform in the installer, even if the platform in the cluster is still just "baremetal".
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.
@dhellmann if IPI was optional, those checks would not be required. Also, I would expect the runtime validations (libvirt socket) to be done during create cluster and not generate igntions.
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.
@hardys i wanted to disrupt the usual flow as little as possible, so for user that do not add the flag to the install-config, nothing would change. I had 2 addtional options that i thought about
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.
suppose that for now we will leave BMH validation as is ( it does not really hurt us, we will just fill in dummy values, and we will use LibvirtURI field in baremetal platform to signal if it is assisted-installer setup. the code will look like:
if p.LibvirtURI == "assisted-installer" {
skip libvirt interface validation
}
@stbenjam @hardys
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.
Magic string values aren't ok here -- I think the consensus from Steve and I are that the IPI-specific validations should be moved to be later, so you can do the UPI workflow with the baremetal platform.
Uh oh!
There was an error while loading. Please reload this page.
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.
If you are just looking to iterate quickly, then I'd suggest doing it in a branch/fork. That worked well for us early on in baremetal IPI days, because we could iterate really quickly without the scrutiny that comes with merging to the installer master branch.
(That approach has its downsides too, since eventually you'll need it to make it to master and needs to get reviewed. We spent quite a long time addressing the installer team's feedback on our large PR to merge our fork.)
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.
@stbenjam do you think thats something someone external to the team can develop? I'm concerned this is not a trivial effort and implies only long term solution?
do we see a path for an internal only flag? e.g. not supported / documented outside this usage path?
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.
Yes, we can help - @dhellmann is going to put together a proposal to make sure we understand exactly what you need.
#3794 (comment)