New deployment can sometimes be started absent any triggers

[ironcladlou]

This is a followup of the analysis from #2721. The following scenario can result surprising deployment behavior:

1. Create DC with no triggers,
2. Perform a manual deployment with osc deploy --latest
3. Delete the deployment/RC,
4. Update a DC field other than LatestVersion or wait for a reflector sync interval (~ 2 minutes)
5. Observe the auto-creation of a deployment named the same as the deleted deployment

[abhgupta]

Shouldn't this be considered expected behavior? A deployment is expected and it is not found and so a new deployment is created.

[liggitt]

Working as coded, yes. As expected, probably not.

[abhgupta]

@liggitt We would probably need a way to prevent a new deployment from being created for a DC. Hence marked this as an enhancement rather than a bug.

[ironcladlou]

Updated description to mention that the re-deployment will happen not only when the DC is modified but also during a reflector sync cycle.

[0xmichalis]

So a DC w/o triggers shouldn't result in a new deployment right? We could add a triggers check in the dc controller (before minting a new deployment) and have an annotation check alongside (that annotation will be set by deploy --latest so we can distinguish manually kicked deployments). Thoughts?

The problem specific to what is described in the first post seems to be:

1. DC w/o triggers has version 0.
2. deploy --latest bumps the version to 1, the dc controller picks up the change and creates a new deployment
3. Deployment gets deleted but the DC stays with version 1.
4. Next update brings the dc controller handling a dc with version 1 but no deployments so it will create one.

[ironcladlou]

So a DC w/o triggers shouldn't result in a new deployment right?

Not necessarily; if you manually deploy with deploy --latest you should get a new deployment whether triggers are defined or not.

If you did have a config change trigger, how would the system recognize that the intent of the user in deleting the deployment was "disable deployments"?

I think what's missing from the issue right now is use cases from the user's perspective. What are they trying to accomplish by actually deleting the deployment directly (instead of say, scaling it down or redeploying)? Here are some reasons I can think that a user might try to do this:

• I rolled out something I didn't want and I need to delete the deployment and disable all deployment triggering while I reassess
• I rolled out something that failed and I'm trying to re-deploy and am going about it in a non-ideal way
• I'm trying to delete my deployment as part of deleting my deploymentconfig and am going about it in a non-ideal way

Are any of these valid? Are there more?

[0xmichalis]

It seems like trying to delete a deployment manually is wrong.

If you rolled out by mistake:

$ oc deploy DC --cancel
# tweak DC 
$ oc deploy DC --latest

If you want to delete the dc:

$ oc delete DC
# everything else should be reaped

If you want to remove older/failed deployments:

# maybe contact your administrator?
$ oadm prune deployments

Maybe a document somewhere "Why you shouldn't manually delete deployments" would be helpful?