I faced a behavior that seems intended but forces me to recreate my service to solve it. If you have another solution to avoid this.
Let me explain the context and the approach. First I need to run an application which can only have one instance due to the database lock it generates. What I did to get this behavior:
I run an application in a service with a single instance (min/max)
The application is deployed
I change a value in the variables
I restart a deployment
I notice that a deployment of 2 instances is starting
My application managing a lock in the DB the 2nd instance fail
I decide to cancel the deployment
I always find the previous vm deployed
I decide to stop the application to remove everything
The application stops but I still have the old vm deployed so at each new start it launches me 2 instances and I leave in the lock
I have to delete the app and recreate it to clean entirely the deployed VM
If you have a solution to avoid deletion of my service to resolve this behavior it will be very nice.
This is normal because we configured this default behavior for all applications to avoid downtime. A new instance is already setup before the old one is removed.
In your case, correct me if I’m wrong, but you want to change the default deployment behavior. Instead of having a new instance to be created, you prefer having the current one stopped, then a new one created.
Can you please confirm this is the behavior you would like to have?
It’s not critic for us actually cause It’s for a devops tool and I can delete and recreate my application in 2 minutes if I need to wait this new feature.
So I say in MOSCOW language: " Should have this if at all possible"