Details
-
Enhancement
-
Resolution: Done
-
Major
-
2.7 CR1
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
No
Description
Currently DeploymentConfigs make reference to generic `latest` imagestream tags. When imagestream latest tag is changed, for instance when there is a upgrade from 2.7 to 2.8, deployment config rolling out is triggered. There is a triggered configured to enable that.
The issue is that when there is an uprade. The operator needs to change deployment config AND imagestream. Currently, those two changes require two deployment rolling outs. During the first deployment roll out inconsistencies between deployment config and imagestream may happen. Example to illustrate both scenarios:
- DC 2.7 and imagestream 2.7. Operator upgrades DC 2.7 -> 2.8. New deployment rolling out of DeploymentConfig 2.8 with imagestream of 2.7. Thus, inconsistency. The image 2.7 may not support deployment config of 2.8. After that, the operator woud upgrade the imagestream to 2.8 reaching out steady state.
- DC 2.7 and imagestream 2.7. Operator upgrades Imagestream 2.7 -> 2.8. New deployment rolling out of DeploymentConfig 2.7 with imagestream of 2.8. Thus, inconsistency. The image 2.8 may not start with DC 2.7. After that, the operator would upgrade the DC to 2.8 reaching steady state.
Furthermore, the operator needs to wait for the first deployment to finish in order to run second one. Making the code harder to implement.
The deployment config has a release and the referenced imagestream should have the same release, instead of generic "latest". That way, the operator can change deployment configuration and referenced image with a single step and only one consistent deployment rolling out would happen.