In the current implementation, we generate new deployments for each replica set other than the one that has the public listeners (e.g., main). When we rollout a new version of the app, we do rolling upgrade on the main group, hence we can do automated rollouts.
However, this approach is not great and it doesn't make sense for someone to do this in production. For development/testing, someone can simply start a new app deployment and kill the old one.
This PR changes the deployment such that:
we now generate unique deployments for all groups (including main)
we generate unique name for the listener service iff the user wants that; this allows the user to reuse the same listener across multiple app versions - makes it easy to do port-forwarding, curl the same IP, etc.
we added a "version" label to the deployments/HPAs/listeners, s.t., we can easily delete old deployments; e.g., kubectl delete all --selector=version=foo deletes all the k8s resources for the app version foo.
In the current implementation, we generate new deployments for each replica set other than the one that has the public listeners (e.g., main). When we rollout a new version of the app, we do rolling upgrade on the main group, hence we can do automated rollouts.
However, this approach is not great and it doesn't make sense for someone to do this in production. For development/testing, someone can simply start a new app deployment and kill the old one.
This PR changes the deployment such that:
kubectl delete all --selector=version=foodeletes all the k8s resources for the app version foo.