-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Allow make e2e-setup-certmanager to work on any cluster #5612
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
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: wallrj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
f493b7c
to
a1de903
Compare
a1de903
to
72f2c24
Compare
Modify the e2e make script to allow images to be pushed to a public registry, and install cert-manager to currently configure KUBECONFIG cluster. This allows me to compile and deploy cert-manager on an Azure AKS cluster for example. Signed-off-by: Richard Wall <richard.wall@jetstack.io>
72f2c24
to
a3cb03d
Compare
@irbekrm Please try this out. The reason for the E2E failures was that I'd accidentally removed the dns01 private networking settings. Fixed now. |
make --jobs e2e-setup-bind USE_EXISTING_CLUSTER=true SERVICE_IP_PREFIX=10.56.0 Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Thanks @wallrj I've not run this yet, but took a look at the commands, I have a couple optional suggestions:
I find the existing test setup confusing in that does already use the existing cluster, but only as long as it's a Kind cluster named 'kind', maybe it would be good if this PR could make that clearer.
or
would be clearer/more conventional (we have a couple examples of doing it like this in closed source) What do you think?
I am not sure if you agree, but I find the connection between USE_EXISTING_CLUSTER env var and users having to specify a registry a bit unclear. I also think that it's possible to have a kind cluster with a different name that you want to target and do want to load images (I have that use case for kind clusters that are created by another setup script). So I would rather have this split into two steps with an additional command that pushes images to a registry, i.e:
Let me know what you think- I think this PR will be useful in either form. |
make --jobs e2e-setup-ingressnginx USE_EXISTING_CLUSTER=true SERVICE_IP_PREFIX=10.56.0 Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
Signed-off-by: Richard Wall <richard.wall@jetstack.io>
@wallrj: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
@irbekrm I agree with you that the interplay between USE_EXISTING_CLUSTER and OCI_REGISTRY_BASE was not intuitive.
I tried but failed to get conditionally use an external OCI registry for the images of all the other e2e requirements, such as pebble, bind, helm etc. Each of those needed to be modified to use different helm chart values, depending on whether the Docker images were being loaded or had been pushed to an external registry. I'll close this PR and hope that you'll have some time to review and try out #5655 |
Modify the e2e make script to allow images to be pushed to a public registry, and install cert-manager to currently configure KUBECONFIG cluster.
This allows me to compile and deploy (redeploy) cert-manager on an Azure AKS cluster for example.
For example:
Another example, showing how to deploy to GKE using Docker images pushed to a private GCR registry.