Red Hat Bugzilla – Bug 1257576
possible breaking change in oc 1.0.5
Last modified: 2015-11-23 16:17:43 EST
Description of problem: Looks like oc 1.0.5 introduces a compatibility issue. I'd suggest we don't break backward compatibility with micro releases. Same thing worked with 1.0.4 Version-Release number of selected component (if applicable): oc v1.0.5 kubernetes v1.1.0-alpha.0-1605-g44c91b1 How reproducible: always Steps to Reproduce: 1.oc new-app --docker-image=openshift/ruby-20-centos7\~https://github.com/openshift/ruby-hello-world --name=myapp Actual results: > Error: BuildConfig "myapp" is invalid: triggers[2].type: invalid value 'ConfigChange': invalid trigger type Expected results: > imagestreams/ruby-20-centos7 > imagestreams/myapp > buildconfigs/myapp > deploymentconfigs/myapp > services/myapp Additional info: some thoughts about versioning policy bug 1235445
I don't seem to be able to reproduce it, could you provide more info? $ oc version oc v1.0.5-67-gc9cb0b6 kubernetes v1.1.0-alpha.0-1605-g44c91b1 $ oc new-app --docker-image=openshift/ruby-20-centos7\~https://github.com/openshift/ruby-hello-world --name=myapp imagestreams/ruby-20-centos7 imagestreams/myapp buildconfigs/myapp deploymentconfigs/myapp services/myapp WARNING: We created an image stream "myapp", but it does not look like a Docker registry has been integrated with the server. Automatic builds and deployments depend on that integration to detect new images and will not function properly. Build "myapp" created and started - you can run `oc status` to check the progress. Service "myapp" created at 172.30.98.73 with port mappings 8080. Run 'oc status' to view your app.
Not sure what can I say more, perhaps it could be related to the underlying environment? > [fedora@akostadi-fedora22-client ~]$ oc version > oc v1.0.5 > kubernetes v1.1.0-alpha.0-1605-g44c91b1 > [fedora@akostadi-fedora22-client ~]$ oc new-project asdfg > Now using project "asdfg" on server "https://openshift-137.example.com:8443". > [fedora@akostadi-fedora22-client ~]$ oc new-app --docker-image=openshift/ruby-20-centos7\~https://github.com/openshift/ruby-hello-world --name=myapp > imagestreams/ruby-20-centos7 > imagestreams/myapp > Error: BuildConfig "myapp" is invalid: triggers[2].type: invalid value 'ConfigChange': invalid trigger type > deploymentconfigs/myapp > services/myapp This is from the underlying environment: > [root@openshift-137 ~]# openshift version > openshift v3.0.1.0-528-g8c2fe51 > kubernetes v1.0.0
Ben / Cesar, any clue here?
This happens when I run it against OSE.3.x using 1.0.5 (or 1.0.4). I don't see the error when I run the same test against an EC2 instance.
Here's more information on what we tried. oc version | client platform | master platform | status | 1.0.4 | Mac | OSE | F | 1.0.4 | Linux | OSE | P | 1.0.5 | Mac | OSE | F | 1.0.5 | Linux | OSE | F | All passed when run against EC2 (devenv-fedora_xxx)
From the above test matrix, it looks like there are some differences between the client verison for Mac vs Linux as well.
ConfigChange is definitely a new trigger that was introduced, so i can understand the server side not recognizing it, but it should ignore it..I guess our validation rules were a bit aggressive. I'm not sure what we can do now...the only viable fix would be for the client tools to know what version of the backend they are talking to (And not just an api version) and not add the ConfigChange trigger if they are talking to an older server that is going to fail the validation. Clayton, how bad did we mess up here? :)
related: https://github.com/openshift/origin/issues/4447
The OSE version has this version information. [root@openshift-138 ~]# oc version oc v3.0.1.0-528-g8c2fe51 kubernetes v1.0.0
Not a fix for existing OSE versions, but in the future we'll be less strict about validating trigger names when this gets merged: https://github.com/openshift/origin/pull/4556 It will allow new triggers to be added without breaking old versions of servers.
*** Bug 1259263 has been marked as a duplicate of this bug. ***
we discussed this on the bug scrub today and the proposed solution is to catch the validation failure in new-app and then recreate the buildconfig without the trigger and resubmit it.
PR https://github.com/openshift/origin/pull/4613
PR #2: https://github.com/openshift/origin/pull/4635
Verified with b0a2fa5 client against > openshift v3.0.1.900-185-g2f7757a