You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2020/09/18 00:36:46 UTC
[GitHub] [openwhisk-deploy-kube] ningyougang opened a new pull request #639: Add helm release to invoker pod
ningyougang opened a new pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639
If want to deploy two helm release openwhisk cluster, when the second helm release cluster's invokerN pod is restarting, it will delete the first helm release's invokerN runtime pods.
Because when invokerN pod is starting, it will delete runtime pods with label(invoker=invokerN) only. e.g.
https://github.com/apache/openwhisk/blob/master/core/invoker/src/main/scala/org/apache/openwhisk/core/containerpool/kubernetes/KubernetesContainerFactory.scala#L65
in order to avoid `delete other helm release invokerN's runtime pod`, it is better to add helm release to invoker pod, and when invoker pod is starting, add label(release=xxxxxx) together with label(invoker=invokerN) to delete runtime pods.
another brother pr: https://github.com/apache/openwhisk/pull/4979
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-deploy-kube] dgrove-oss commented on pull request #639: Add helm release to invoker pod
Posted by GitBox <gi...@apache.org>.
dgrove-oss commented on pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639#issuecomment-694579937
Repeating the question from the core repo....does deploying to separate namespaces avoid the problem? My intuition is that it should.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-deploy-kube] dgrove-oss edited a comment on pull request #639: Add helm release to invoker pod
Posted by GitBox <gi...@apache.org>.
dgrove-oss edited a comment on pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639#issuecomment-694587057
I don't object too much to the change, but be aware that when you do a `helm delete` and undeploy the chart, it doesn't remove the action containers (the chart had no idea they exist). So using a namespace for more than a single deployment is a bit dicey in any case. Part of the reason the invoker deletes all the pods when it starts up is to try to clean up from previous deployments in the same namespace.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-deploy-kube] ningyougang commented on pull request #639: Add helm release to invoker pod
Posted by GitBox <gi...@apache.org>.
ningyougang commented on pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639#issuecomment-694581057
@dgrove-oss ,hi
yes, in two kubernateds namespace can avoid the problem.
but some users may deploy two deployments in same namespace.
hm..i think add a one more lable(release=xxxx) it is more carefully.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-deploy-kube] style95 merged pull request #639: Add helm release to invoker pod
Posted by GitBox <gi...@apache.org>.
style95 merged pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-deploy-kube] ningyougang edited a comment on pull request #639: Add helm release to invoker pod
Posted by GitBox <gi...@apache.org>.
ningyougang edited a comment on pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639#issuecomment-694581057
@dgrove-oss ,hi
yes, using two kubernates namespace can avoid the problem.
but some users may deploy two deployments in same namespace.
hm..i think add a one more lable(release=xxxx) it is more carefully.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [openwhisk-deploy-kube] dgrove-oss commented on pull request #639: Add helm release to invoker pod
Posted by GitBox <gi...@apache.org>.
dgrove-oss commented on pull request #639:
URL: https://github.com/apache/openwhisk-deploy-kube/pull/639#issuecomment-694587057
I don't object to much to the change, but be aware that when you do a `helm delete` and undeploy the chart, it doesn't remove the action containers (the chart had no idea they exist). So using a namespace for more than a single deployment is a bit dicey in any case. Part of the reason the invoker deletes all the pods when it starts up is to try to clean up from previous deployments in the same namespace.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org