-
Notifications
You must be signed in to change notification settings - Fork 277
feat(*): ensure traffic target in dest namespace #4151
Conversation
pkg/catalog/traffictarget.go
Outdated
@@ -201,7 +201,7 @@ func (mc *MeshCatalog) getTCPRouteMatchesFromTrafficTarget(trafficTarget smiAcce | |||
|
|||
// isValidTrafficTarget checks if the given SMI TrafficTarget object is valid | |||
func isValidTrafficTarget(t *smiAccess.TrafficTarget) bool { | |||
return t != nil && t.Spec.Rules != nil && len(t.Spec.Rules) > 0 && hasValidRulesKind(t.Spec.Rules) | |||
return t != nil && t.Spec.Rules != nil && len(t.Spec.Rules) > 0 && hasValidRulesKind(t.Spec.Rules) && t.Namespace == t.Spec.Destination.Namespace |
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 wonder if it'd be prudent to move the t != nil && t.Spec.Rules != nil && len(t.Spec.Rules) > 0
checks inside the hasValidRulesKind()
function to lower the complexity of this line.
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.
Another idea - it might be good to put a log statement here so when everything is good but the namespace is not the destination namespace - then we could Trace log a statement. This may help us debug a problem.
@michelleN Would it make sense to also to a check in our ValidationWebhook (and add it to a more general SMI validation) -- to make sure that the One other idea to explore -- when the |
Codecov Report
@@ Coverage Diff @@
## main #4151 +/- ##
==========================================
+ Coverage 69.34% 69.83% +0.48%
==========================================
Files 212 211 -1
Lines 11429 11472 +43
==========================================
+ Hits 7925 8011 +86
+ Misses 3451 3408 -43
Partials 53 53
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
6e4855d
to
c960417
Compare
647b1a9
to
d92a61f
Compare
193bbd4
to
7e642fa
Compare
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
This is going to save us a lot of headaches!
@@ -202,7 +202,7 @@ var _ = OSMDescribe("Test HTTP traffic with SMI TrafficTarget", | |||
|
|||
// createPolicyForRoutePath creates an HTTPRouteGroup and TrafficTarget policy for the given source, destination and HTTP path regex | |||
func createPolicyForRoutePath(source, sourceNamespace, destination, destinationNamespace, pathRegex string) (smiSpecs.HTTPRouteGroup, smiAccess.TrafficTarget) { | |||
routeGroupName := "test-route" | |||
routeGroupName := source + "-" + destination |
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.
Should we use fmt.Sprintf()
to follow Go best practices?
return nil, errors.Errorf("The traffic target namespace (%s) must match spec.Destination.Namespace (%s)", | ||
trafficTarget.Namespace, trafficTarget.Spec.Destination.Namespace) |
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'm not opposed returning errors.Errorf
, but that would make it hard in the future should we want to differentiate between different types of errors returned by this validator.
I don't know that we have settled on a standard for this repo.
We tend to create an error and place it in the errors.go
file in the package.
var ErrTrafficTargetNamespaceMismatch = errors.New("traffic target namespace mismatch")
and then here return nil, ErrTrafficTargetNamespaceMismatch
but also before the return log the full statement
log.Error().Err(ErrTrafficTargetNamespaceMismatch).Msgf("The traffic target namespace (%s) must match spec.Destination.Namespace (%s)", trafficTarget.Namespace, trafficTarget.Spec.Destination.Namespace)`
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.
@draychev the recommended way to log errors currently is as follows:
- For dynamic error messages without error codes, use
errors.Errorf(), errors.New()
. - For static errors messages previously defined in errors.go, define it in
pkg/errcode/errcode.go
instead so it can be logged similar to other error codes with the ability to publish metrics per error code.
I am not opposed to defining errors in errors.go if they don't need additional data to be encoded in them, though the errcode model should be adopted to get the benefits of tooling we build to inspect error codes instead of error messages.
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 just merged #4160 and this is conflicting with the changes I recently checked in
7e642fa
to
9b9fb53
Compare
9b9fb53
to
45fa02f
Compare
+ Adds a validator for traffic target specifically requiring that the namespace of a traffic target matches the destination namespace. + Updates chart template for validating webhook configuration to optionally enable validation of SMI Traffic Targets + Adds value for toggling validating SMI traffic target in values.yaml + Updates chart README + Updates e2es to create traffic targets in destination namespace + Adds e2e for SMI traffic target validation + Adds validating traffic target rule for scenario when osm-controller is creating/updating validating webhook config partially resolves openservicemesh#4116 Signed-off-by: Michelle Noorali <[email protected]>
45fa02f
to
be9808b
Compare
+ Adds a validator for traffic target specifically requiring that the namespace of a traffic target matches the destination namespace. + Updates chart template for validating webhook configuration to optionally enable validation of SMI Traffic Targets + Adds value for toggling validating SMI traffic target in values.yaml + Updates chart README + Updates e2es to create traffic targets in destination namespace + Adds e2e for SMI traffic target validation + Adds validating traffic target rule for scenario when osm-controller is creating/updating validating webhook config partially resolves openservicemesh#4116 Signed-off-by: Michelle Noorali <[email protected]>
Addressing PR comment openservicemesh#4151 (comment) Signed-off-by: Michelle Noorali <[email protected]>
+ adds var ErrTrafficTargetNamespaceMismatch + updates e2e line to use fmt.Sprintf Addressing PR comment openservicemesh#4151 (comment) and openservicemesh#4151 (comment) Signed-off-by: Michelle Noorali <[email protected]>
+ adds var ErrTrafficTargetNamespaceMismatch + updates e2e line to use fmt.Sprintf Addressing PR comment openservicemesh#4151 (comment) and openservicemesh#4151 (comment) Signed-off-by: Michelle Noorali <[email protected]>
+ Adds a validator for traffic target specifically requiring that the namespace of a traffic target matches the destination namespace. + Updates chart template for validating webhook configuration to optionally enable validation of SMI Traffic Targets + Adds value for toggling validating SMI traffic target in values.yaml + Updates chart README + Updates e2es to create traffic targets in destination namespace + Adds e2e for SMI traffic target validation + Adds validating traffic target rule for scenario when osm-controller is creating/updating validating webhook config partially resolves openservicemesh#4116 Signed-off-by: Michelle Noorali <[email protected]> Signed-off-by: Sneha Chhabria <[email protected]>
+ Adds a validator for traffic target specifically requiring that the namespace of a traffic target matches the destination namespace. + Updates chart template for validating webhook configuration to optionally enable validation of SMI Traffic Targets + Adds value for toggling validating SMI traffic target in values.yaml + Updates chart README + Updates e2es to create traffic targets in destination namespace + Adds e2e for SMI traffic target validation + Adds validating traffic target rule for scenario when osm-controller is creating/updating validating webhook config partially resolves openservicemesh#4116 Signed-off-by: Michelle Noorali <[email protected]>
Description:
feat(*): add traffic target validation
requiring that the namespace of a traffic target matches the
destination namespace.
validation of SMI Traffic Targets
Signed-off-by: Michelle Noorali [email protected]
Testing done:
Affected area:
Please answer the following questions with yes/no.
Does this change contain code from or inspired by another project? No
Is this a breaking change? Yes