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

Camel-K - uninstall and namespace deletion w/ k8s let all Camel-K Integrations in this namespace alive #2533

Closed
catshout opened this issue Jul 28, 2021 · 1 comment

Comments

@catshout
Copy link

I've installed Camel-K in a namespace "camel-k" in a GCP (Google Cloud Platform) k8s cluster. As next I deployed 1 simple integration
hello.zip
in this namespace.

I performed the following commands to uninstall and re-install Camel-K

kamel uninstall --all --global
kubectl config set-context --current --namespace=default
kubectl delete namespace camel-k
kubectl create namespace camel-k
kubectl config set-context --current --namespace=camel-k
kubectl create secret generic kaniko-secret --from-file=/home/cas-dev-gke/kaniko-secret.json
kamel install --build-publish-strategy=Kaniko --registry gcr.io --organization cas-dev-gke --registry-secret kaniko-secret --global

I'd expect that the Camel-K operator will become available but former Integrations in this namespace must be deployed again.

As I experienced all Integrations in this namespace Camel-K are automatically deployed after Camel-K re-install.

Side note: An uninstall of Camel-K 1.4 und re-install of Camel-K 1.5 leave the Camel-L operator in a deadlock. We did have to remove all Integrations and re-deploy.

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant