Bug 1257576 - possible breaking change in oc 1.0.5 [NEEDINFO]
possible breaking change in oc 1.0.5
Product: OpenShift Origin
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
Unspecified Unspecified
medium Severity high
: ---
: ---
Assigned To: Cesar Wong
Yan Du
: Regression
: 1259263 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-08-27 07:36 EDT by Aleksandar Kostadinov
Modified: 2015-11-23 16:17 EST (History)
10 users (show)

See Also:
Fixed In Version: openshift-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-23 16:17:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
bparees: needinfo? (ccoleman)

Attachments (Terms of Use)

  None (edit)
Description Aleksandar Kostadinov 2015-08-27 07:36:48 EDT
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:

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
Comment 1 Fabiano Franz 2015-08-27 16:14:17 EDT
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 
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 with port mappings 8080.
Run 'oc status' to view your app.
Comment 2 Aleksandar Kostadinov 2015-08-27 16:46:27 EDT
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
Comment 3 Fabiano Franz 2015-08-28 16:56:07 EDT
Ben / Cesar, any clue here?
Comment 4 Peter Ruan 2015-08-28 17:12:42 EDT
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.
Comment 5 Peter Ruan 2015-08-28 17:55:58 EDT
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)
Comment 6 Peter Ruan 2015-08-28 17:57:39 EDT
From the above test matrix, it looks like there are some differences between the client verison for Mac vs Linux as well.
Comment 7 Ben Parees 2015-08-28 21:52:44 EDT
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? :)
Comment 8 Ben Parees 2015-09-01 18:17:37 EDT
Comment 9 Peter Ruan 2015-09-01 18:24:01 EDT
The OSE version has this version information.
[root@openshift-138 ~]# oc version
oc v3.0.1.0-528-g8c2fe51
kubernetes v1.0.0
Comment 10 Rodolfo Carvalho 2015-09-07 08:37:35 EDT
Not a fix for existing OSE versions, but in the future we'll be less strict about validating trigger names when this gets merged:


It will allow new triggers to be added without breaking old versions of servers.
Comment 11 Ben Parees 2015-09-08 11:36:07 EDT
*** Bug 1259263 has been marked as a duplicate of this bug. ***
Comment 12 Ben Parees 2015-09-08 11:36:55 EDT
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.
Comment 13 Cesar Wong 2015-09-10 10:46:30 EDT
PR https://github.com/openshift/origin/pull/4613
Comment 14 Jordan Liggitt 2015-09-11 16:26:55 EDT
PR #2: https://github.com/openshift/origin/pull/4635
Comment 15 Aleksandar Kostadinov 2015-09-14 07:21:06 EDT
Verified with b0a2fa5 client against
> openshift v3.0.1.900-185-g2f7757a

Note You need to log in before you can comment on or make changes to this bug.