wait-for-deployment too complicated
Opened this issue · 0 comments
Hi, first thanks for your code. I found another way to wait for a deployment so I thought sharing it here.
What I do is this :
First get the current deployment revision :
kubectl
get deployment $DEPLOYMENT_NAME -o json | jq -r '.metadata.annotations."deployment.kubernetes.io/revision"'`
For this to work you need the jq
command installed. If you don't have it or don't want to install, you can also use
kubectl rollout history deployment $DEPLOYMENT_NAME | tail -n 2 | head -n 1 | cut -d ' ' -f 1
(but seems less stable ;) )
I store the output of the previous command (current revision) in an env variable or a temp file.
Then I proceed with the deployment (kubectl apply ...
).
I set a variable NEW_REVISION_NUMBER to CURRENT_REVISION + 1 and prepare to wait for the complete deployment of this new revision.
Then I loop until this command returns OK :
kubectl rollout status deployment $DEPLOYMENT_NAME --revision $NEW_REVISION_NUMBER
.
I also add a timeout for edge cases and deployment errors.
Limitations
Since I only check for the revision number for an increment of 1, I am assuming that there will be no one else doing a rollout at the same time. If that happens, I can take the other rollout for mine and launch other CI process by error.
I think a better way would be to put some metadata on the deployment when deploying it (like a label with a random generated number as value) and wait for a deployment with this metadata to be ready. This would ensure that we are precise about the deployment we are waiting for.
Questions
A question I have not been able to precisely answer by reading the docs is the difference between generation and revision. As far as I understand the generation is a counter for the entire deployment state whereas revision only counts for pod template changes. Is that what you understand too ?