RouteOptions e2e tests #9470
RouteOptions e2e tests #9470
Conversation
jbohanon
added
the
work in progress
github-actions
bot
added
the
keep pr updated
|
Visit the preview URL for this PR (updated for commit 7203bd0): https://gloo-edge--pr9470-jbohanon-rtopts-e2e-0smmv1gi.web.app (expires Mon, 20 May 2024 23:29:31 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 77c2b86e287749579b7ff9cadb81e099042ef677 |
…gloo into jbohanon/rtopts-e2e-tests
test/kubernetes/e2e/features/route_options/testdata/httproute1-bad-extension.yaml
Show resolved
Hide resolved
…gloo into jbohanon/rtopts-e2e-tests
|
Issues linked to changelog: |
|
/kick |
jbohanon
removed
the
work in progress
| // Manually apply our manifests so we can assert that basic rto exists before applying extra rto. | ||
| // This is needed because our solo-kit clients currently do not return creationTimestamp | ||
| err := s.testInstallation.Actions.Kubectl().ApplyFile(s.ctx, setupManifest) | ||
| s.NoError(err, "can apply "+setupManifest) |
There was a problem hiding this comment.
I think the EventuallyObjects exist check is still valid after we apply the test/kubernetes/e2e/features/route_options/testdata/setup.yaml. We don't need it for any of the other manifests, but it would be good to assert the gateway is created by the deployer.
There was a problem hiding this comment.
But none of the features of the route options plugin affect the behavior of the deployer, nor are they contingent upon the deployer's success. Given that, I think it makes more sense to let the routing fail and depend on the deployer tests to catch issues that may arise with that feature.
There was a problem hiding this comment.
I think it's more similar to the post installation checks where we assert the gloo gateway is present. If we remove this assertion, then if a setup file is missing a gateway or something is rejecting the gateway, the test will continue and fail on the longer curl assertion. If we assert here, it fails earlier.
The deployer tests are checking a different setup file, so they may use a different setup file. I would fine if we removed the assertion and all the tests used the same gateway as the deployer, but that would also limit the flexibility of the tests.
Description
Rewrite the route options e2e tests for the k8s gateway plugin to match the vhopts patterns.
Additionally, new test cases were added to cover different edge cases.
TODO: open issue to track the open questions left by this effort:
BOT NOTES:
resolves https://github.com/solo-io/solo-projects/issues/6082