Skip to content
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

[Helm] Trying to install a second release #950

Closed
katlimruiz opened this issue May 15, 2020 · 7 comments · Fixed by #1009
Closed

[Helm] Trying to install a second release #950

katlimruiz opened this issue May 15, 2020 · 7 comments · Fixed by #1009
Assignees
Labels
bug An issue reporting a potential bug

Comments

@katlimruiz
Copy link

Describe the bug
I have a cluster where I want to setup many different websites, each with its own nginx ingress.
I already have one that is running correctly. I used this command:

helm install myapp1 nginx-stable/nginx-ingress --namespace myapp1 --set controller.ingressClass=nginx-myapp1

which the ingressClass matches with an ingress resource. This runs fine.

So I want to add another website. I want to use this command:

helm install myapp2 nginx-stable/nginx-ingress --namespace myapp2 --set controller.ingressClass=nginx-myapp2

However, this gives me the following error:

Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: transportservers.k8s.nginx.org, existing_kind: apiextensions.k8s.io/v1beta1, Kind=CustomResourceDefinition, new_kind: apiextensions.k8s.io/v1beta1, Kind=CustomResourceDefinition

Expected behavior
The second installation should be inserted correctly. Since it is under a different namespace and a different release name.

Your environment

  • Version of the Ingress Controller = NGINX Ingress Controller 1.7.0
  • Version of Kubernetes = 1.15
  • Kubernetes platform (e.g. Mini-kube or GCP) = Azure
  • Using NGINX or NGINX Plus = NGINX
@Dean-Coakley Dean-Coakley self-assigned this May 15, 2020
@Dean-Coakley Dean-Coakley added the bug An issue reporting a potential bug label May 15, 2020
@Dean-Coakley
Copy link
Contributor

@katlimruiz Thanks for the bug report. We will fix it!

@katlimruiz
Copy link
Author

cool, I thought I was doing something wrong 👍

when is the next release?

@Dean-Coakley
Copy link
Contributor

Next release is planned for June/July.

The fix should be in master shortly. Which leaves you with some options for work arounds in the meantime:

  • Download the chart locally and do similar edits
  • Move to using the nginx-edge/nginx-ingress chart. Note that this is not recommended for production use.
  • Do helm template [chart] and edit the output to no longer have the CRDs.

Sorry for the hassle

@Dean-Coakley
Copy link
Contributor

Additionally, If you are not using our CRDs(if you are using ingress resources only) the following workaround should work:

  • Simply set controller.enableCustomResources to false.

@katlimruiz
Copy link
Author

katlimruiz commented May 16, 2020 via email

@Dean-Coakley
Copy link
Contributor

Ah, no problem.

If you are using CRDs you will route requests using our custom VirtualServer/VirtualServerRoute resources which are an alternative to Ingress resources:
https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#virtualserver-specification

If you are not using CRDs you will route requests via Ingress resources:
https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/basic-configuration/

You can check the manifests you have deployed. Or verify the deployed resources with kubectl.
E.g something like:
kubectl get ingress -n myapp1 // check if you have ingresses deployed in the myapp1 namespace
kubectl get vs -n myapp1 // check if you have virtualservers deployed in the myapp1 namespace

If you have no virtualserver/vs resources in any namespace you can disable them as described above.
You then should be able to install the Ingress Controller in multiple namespaces via helm without issues.

Hope that clears things up.

@katlimruiz
Copy link
Author

katlimruiz commented May 18, 2020

It worked. I was not using the new CRDs, therefore I set the flag as false, and it worked as expected.
Hope the bug gets fixed eventually.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An issue reporting a potential bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants