-
Notifications
You must be signed in to change notification settings - Fork 118
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
MAISTRA-1071 Add manifest namespace validation #462
Conversation
if err := r.Client.Get(context.TODO(), client.ObjectKey{Namespace: r.Instance.GetNamespace(), Name: common.MemberRollName}, smmr); err != nil { | ||
if !apierrors.IsNotFound(err) { | ||
// log error, but don't fail validation: we'll just assume that the control plane namespace is the only namespace for now | ||
log.Error(err, "failed to retrieve SMMR for SMCP") |
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's probably worth returning the error and letting the reconciliation restart. If there's a gateway that references a namespace that is legitimate, then we'll error when we validate, which will be a false error message.
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.
So you want to restart reconciliation without logging an error in this case?
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.
The thing is that this will probably only happen rarely, and even if it happens, it will only have an impact if you have a gateway outside the control plane namespace. The idea with just logging and continuing was that 99% of the time it'll be alright, because the gateway is in the cp namespace anyway
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 believe you can just return the error from the reconcile loop and let it do its thing. I don't remember if we need to log it and return it, or just return it. @luksa?
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 that it's probably unlikely that it will fail and unlikely that a namespace other than the control plane will be used. Maybe keep track of the fact that the smmr lookup failed and then if there's a validation failure, you can return the smmr error instead. wdyt?
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.
Yeah, I think that makes sense
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 fixed it now. While at it, I found another issue; I had forgotten to split the manifests (by "---") so was only looking at the first manifest in the output of each helm template (which for the gateways are multiple).
733f97e
to
5c3beb2
Compare
FYI I ran the validation function 1k times and it takes 21ms on average on my machine, so should be okay |
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.
LGTM but I'm wondering why we need to consider the member namespaces when checking the manifests. Aren't all resources deployed in the control plane namespace? If yes, then we could perform the validation when we render the charts.
The gateways are an exception in that they can be deployed to any namespace by providing a The reason I added this in a generic fashion is that things like this could come up again in future versions of Istio, and it might not just be restricted to gateways |
Adding a hold as this will go into 1.1.5 |
/cherry-pick maistra-1.2 |
@dgn: #462 failed to apply on top of branch "maistra-1.2":
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. |
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This is two parts: