Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Function Update if config/secret changes #1224
If a secret/configmap value changes - the function should update with the new value.
In the case of pool manager, this works as the specialized pod always picks up the new value from configmap/secret.
In the case of newdeploy - this controller terminates the old pod which in turn creates new pods with new values of configmap/secret.
Thinking more about the implementation and after looking at issue I think deleting pods like this is a pretty bad idea. Especially for new deploy executor - where if all pods are deleted and if it takes time for new pod to come up then the latency is higher than one would expect from new deploy function.
The closest solution I can think of is similar to kubernetes/kubernetes#76062 - but that is only on the client side and something similar would have to be done on the server side within Fission.
Yeah, agree that would be a problem if under heavy workloads.
Of course, it's better to switch to the new function version. But consider the problem you mentioned, I think we should consider how to migrate traffic from old fn to the new one more smoothly instead of just thinking how fast we can achieve to let user's function get an update.
How about we add SHA of secret/cfgmap to deployment, then we simply update that label to trigger a rolling update? Kubernetes will handle the instance rolling update for us.
And in fact, it adds extra protection to users if their newer function won't come up.
What do you think?
I think the migration of traffic from old to a new pod is taken care of by
SHA of configmap - the reason I don't like because we can potentially have multiple configmaps/secrets per function which creates a lot of extra decisions.
I am inclining towards adding a new annotation/ ENV variable - the value will a simple timestamp called
The PR is now changed and ready for re-review based on the discussion above. The implementation is different for Pool manager vs. new deploy executor and is described below:
Also doc update PR raised: fission/docs.fission.io#140