-
Notifications
You must be signed in to change notification settings - Fork 4.7k
DeploymentConfig behaviour change from 3.6 to 3.7 #18406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
starting as a p1 because it's a regression/change in behavior (possibly intentional and justifiable) |
(if anything it sounds like the 3.6 behavior was broken, so perhaps this was a bug fix in 3.7) |
@bparees From my perspective, a change in the DC - any change - should only be triggered if there is a ConfigChange trigger. That is, after all, why we have the ConfigChange trigger. If anything else in the DC is changed, it does not re-deploy. So if this is intentional behaviour, it would effectively amount to an implicit/hidden trigger on the container image reference being introduced. |
Ok, after further analysis I can see that F-M-P is doing a PUT which triggers the re-deploy. If I do a PATCH with the same content and change the container image reference, it does not seem to trigger a re-deploy. |
What is FMP? |
@Kargakis Sorry, I thought it was a known abbreviation/acronym... it stands for Fabric8 Maven Plugin. |
Can you post the DC before and after doing a PUT and before and after doing a PATCH? cc @tnozicka |
That what I was going to ask, please always provide the DC's YAML and exact steps to reproduce (ideally commands) - it will save us time when trying to understand and resolve the issue. |
Ok, I think I was wrong about the PUT vs PATCH thing. The behaviour is the same regardless. But I will try to provide all the steps with a higher level of detail: Before PUT / PATCH:
After PUT (using F-M-P)
After PATCH
|
And finally, the reason I was wrong about the difference between PUT / PATCH: When you PUT / PATCH an undeployed (i.e. not yet had 'oc rollout' executed against it) application, it seems to work fine, i.e. it does not trigger a deployment. I had executed the PATCH against an undeployed application. Here is the DC before and after an undeployed app has been patched: Before
After
|
Thanks for the info I think I now now what's wrong. The trigger controller won't inject an image because it's paused, but since you set it "manually" the DC controller thinks there has been an image injected and considers that an image change. I think that should be fixable by the DC controller also checking if the trigger isn't paused. There should be an easy way to around it in the mean time: If you are using ImageChangeTrigger always set container's image to " ". Actually that applies in general - if there is a configChangeTrigger never set image to anything else than " ". That way even if you need to do something like PUT or |
@tnozicka Thank you for this suggestion - it worked! EDIT: @tnozicka My earlier experiment was unfortunately not entire correctly placed. It does work - the first time. Any subsequent rollout leads to a problem with the RC complaining about a missing image reference and seems to be an issue you are well aware of: #16728. Can you tell me how I should proceed? This is a huge blocker for my organization - we cannot proceed with upgrade to 3.7+ due to this, as all our projects are dependent on this build and deployment mechanism. Can you backport the fix to a 3.7.x-version, or provide an alternative way short of waiting for 3.9 to be released? Much appreciated. |
I'll check and see how much conflict there will be in |
Not sure whether there will be another release of 3.7.x though. |
backport to 3.7 #18524 |
Hello @tnozicka , I try to apply your workaround from #18406 (comment) which is to set the DC's container.image to " " (string containing a space). Using OSE v3.7.0, I am unable to deploy the DC with container.image set to " " and automatic imageChangeTrigger, the following messages appears in Events "Couldn't deploy version 5: ReplicationController "xxxx-5" is invalid: spec.template.spec.containers[0].image: Required value". |
Hi @jperville, that backport is not merged yet (hitting unrelated flake)
OSE backport will follow once that PR makes it through the queue in Origin ;)
That is strange as this is just short time failure as the image in DC will get eventually rewritten by image trigger causing a new rollout with valid image. |
maybe it doesn't get synced; that part is being fixed in that backport as well |
Both backports are merged now. |
Uh oh!
There was an error while loading. Please reload this page.
In 3.6, using F-M-P which updates the both the container image reference and the image trigger reference, there was no automatic re-deployment when trigger is set to automatic false.
In 3.7, it seems like an update to the container image reference automatically re-deploys.
This breaks our workflow.
Version
oc v3.7.0+7ed6862
kubernetes v1.7.6+a08f5eeb62
features: Basic-Auth
openshift v3.7.0+7ed6862
kubernetes v1.7.6+a08f5eeb62
Steps To Reproduce
3.7:
3.6:
Current Result
3.7:
It will trigger a deployment.
3.6:
Nothing will happen.
Expected Result
3.7:
Nothing should happen (as in 3.6) until a manual rollout command has been executed.
@soltysh @mfojtik @bparees
The text was updated successfully, but these errors were encountered: