-
Notifications
You must be signed in to change notification settings - Fork 224
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
OCPBUGS-27741: Reject Invalid Route Paths with Rewrite-Target Annotation #1791
Draft
gcs278
wants to merge
1
commit into
openshift:master
Choose a base branch
from
gcs278:OCPBUGS-27741-reject-invalid-path-with-rewrite-target
base: master
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.
Draft
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
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.
It appears you only have an instant view of the object here, and don't have the prior view of it, is that correct?
Typically in webhooks you can compare state with the old state. If you can do that, you can make this validation ratchet by allowing the persistence of existing bad configuration, and only validate when there is actually a change to the path/annotation.
That would be safer here, as, presently, in theory, someone could upgrade and this would then prevent any writes to the object until the validation issue has been resolved.
If the validation here fails, I understand that HAProxy will be in a crash loop right? So in theory, the cluster would not be upgradeable anyway, and so the argument is that this doesn't need to ratchet?
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.
Correct. Let me clarify this: what happens with this current non-ratcheting validation when someone updates with a newly invalid route?
I think the answer is: nothing...until the user changes any field on the invalid route. It's not going to cause a K8S cluster melt-down right? Will ALL updates, including status updates made by the openshift-router be rejected too? (that might be okay, but something for me think about...)
On the other hand, ratcheting validation allows the user to still update other fields route while our spec.path still be invalid (but we won't reject yet), correct?
I think if i understand how non-ratcheting validation compares to ratcheting (e.g. non-ratcheting rejects ALL updates to a route), yes, I think we should be okay since the validation I'm adding results in a HAProxy crash loop, which means the user is already broken.
I'd like to confirm if this is a valid use case for doing the sledgehammer of non-ratcheting validation, since, yes, HAProxy will be crashlooping in any of these situations.
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.
Test this, but, I believe it will prevent ALL writes, including status.
Correct, they would only be presented with errors when they change something specific to this validation, the spec path or the annotation in this particular case.
How would this manifest in the cluster? Would it cause an
upgradeable
condition to go false on the cluster operator? If it does, then the user must fix the issue before they upgrade into a version containing this validation, right?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.
Hmm looks like if I try to edit the status via
oc edit route...
it fails, but the router status update appears to be successful despite the non-ratcheting validation.No
upgradeable
condition currently. The problem with doingupgradeable
, is that we want to backport. In theory, I think we could doupgradeable=false
on z streams, but previously the upgrade team didn't like the idea of a single route preventing an entire cluster from upgrading (route admin vs. cluster admin personas), so we used Admin-Acks so the cluster admin could override, which only works for minor level upgrades.Upgradeable=false
is also going to be more painful to implement.The real argument against
upgradeable=false
, is that users that are already in this state (have invalid config), are already broken.Upgradeable
doesn't feel useful when routers are already broken.So, users have a broken HAProxy if they enter this invalid state we are adding validation for. Ratcheting validation would allow them to modify other config fields, but what's the point if they are totally broken? Arguably they should fix the invalid state ASAP. However, the only argument for ratcheting validation is: it is somewhat of a safety mechanism in case we miss an edge case where a newly invalid state WAS actually valid (didn't cause failure). However, it's still ratcheting validation, so eventually if they recreate the route, or try to change spec.path or the rewrite-target annotation, the validation will catch up with them. And this scenario would be a bug we should fix anyways.
So, I don't see any strong reasons to do ratcheting validation. @JoelSpeed Do you agree, or have any thoughts otherwise?
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 use the
--subresource status
flag when tryingoc edit
? You'll need to if the object has a status subresourceI wasn't suggesting to implement an upgradeable false, sorry, I meant, if the routers are already broken, how does the cluster operator look? Does an invalid config today (causing restarting HAProxy) already cause an upgradeable false or some other note in the cluster that would prevent the user upgrading into this while already broken?