SpringBoot Quick Start projects fail in Che

[bmicklea]

Neither of the Spring Boot quick start projects can be properly started in Che on OSIO.

To Reproduce

• Create space and use either of the Spring Boot quick starts.
• Space should appear correctly and builds kick off correctly.
• Go to Codebases section and create a Che workspace.
• Che IDE opens but workspace doesn't start. Error shown isWorkspace not running... in the upper notification center, no other details

• When running the workspace from the Workspace tab in the Che dashboard on OSIO you get this additional error:

Environment

OSIO with Chrome (incognito) on OSX
Che 2.0.17
Jenkins 4.0.12

Confirmed by @DarrenRatcliffe

[bmicklea]

@l0rd and @gorkem - not sure if you're aware of this already but it's a problem since it seems to affect all spring boot project quick starts.

[l0rd]

@bmicklea no I was not. Let me try to reproduce it.

[l0rd]

I've reproduced it. And I confirm that vert.x quickstart work on Che so the problem is related to spring-boot stack only.

[bmicklea]

Thanks @l0rd.

[l0rd]

So it looks like using image rhche/spring-boot instead of registry.devshift.net/che/spring-boot as source of the stack solve the issue. These images should be identical.

[bmicklea]

So that's a change to the Che dockerfile?

[l0rd]

No the Dockerfiles are identical. But instead of using the Docker Hub for Docker images we have switched to registry.devshift.net late last week. I confirm that images are identical (same hash). There may be something in their name that osio don't like...continuing investigating

[ibuziuk]

2017-09-12 17:45:12,274[aceSharedPool-0]  [INFO ] [o.e.c.p.o.c.OpenShiftConnector 840]  - Created ImageStream registry.devshift.net_che_spring-boot.
--
  | 2017-09-12 17:45:14,443[aceSharedPool-0]  [INFO ] [o.e.c.p.o.c.OpenShiftConnector 1437] - Created ImageStreamTag registry.devshift.net_che_spring-boot:che-ws-c067dx0sc9z4kbu79 in namespace ibuziuk-che
  | 2017-09-12 17:45:14,522[aceSharedPool-0]  [ERROR] [o.e.c.a.w.s.WorkspaceManager 683]    - ImageStreamTag che-ws-c067dx0sc9z4kbu79ku1799htx0p3wyl not found!
  | org.eclipse.che.api.core.ServerException: ImageStreamTag che-ws-c067dx0sc9z4kbu79ku1799htx0p3wyl not found!

@l0rd looks like the problem is coupled with the fact that kubernetes names / labels max lenght is 63 chars[1]. During IS creation the last part of the tag is trimmed:

registry.devshift.net_che_spring-boot:che-ws-c067dx0sc9z4kbu79

But workspace manager tries to find IS tag by non-trimmed name che-ws-c067dx0sc9z4kbu79ku1799htx0p3wyl and fails. Basically, switching to a new registry has sufficiently increase IS naming prefix and we started to hit kubernetes names' length limit

[1] kubernetes/kubernetes#12463 (comment)

[ibuziuk]

Have not tested but looks like decreasing length check to 25 should do the trick [1]

[1] https://github.com/eclipse/che/blob/master/plugins/plugin-docker/che-plugin-openshift-client/src/main/java/org/eclipse/che/plugin/openshift/client/OpenShiftConnector.java#L1108

[ldimaggi]

Screenshot of the error:

[l0rd]

Thanks @ibuziuk for the analysis. @bmicklea we will fix that tomorrow.

[ibuziuk]

@l0rd tested on minishift - seems to work just fine.
This fix should work for all pre-defined rhche stacks - eclipse-che/che#6245

[bmicklea]

Great news - thanks!

[l0rd]

@ibuziuk great job! Now we need to decide if:

• we ask Roman to do an hot fix release of eclipse/che that contains your fix
• we provide a temporary workaround (e.g. use rhche/spring-boot in osio stacks.json).

I would rather go with this second option. It's easier and we will be able to fix the problem in prod in a less than an hour. @ibuziuk what do you think?

[ibuziuk]

@l0rd +1 for the second option, but we would also need to use rhche for all the other stacks (vertx seems to be the only one which is not affected)

[l0rd]

@ibuziuk redhat-developer/rh-che#333

[l0rd]

Reopening it. PR is merged but we need to wait the build before it's available on OSIO.

[l0rd]

@bmicklea I've just verified that this is fixed on OSIO. Let me know if we can close it.

[ldimaggi]

Looks OK - Brad, is this working for you?

[bmicklea]

Strangely it's still not working for me on 2.0.18 - is that what you had @ldimaggi?

[ldimaggi]

Yes - 2.0.18 - just tried again and it was able to open the workspace.

[bmicklea]

It's working now, closing.

[ldimaggi]

Automated test to verify that each quickstart can open its Che workspace:
https://ci.centos.org/view/Devtools/job/devtools-test-end-to-end-openshift.io-chequickstartTest/

[l0rd]

@ldimaggi that is great!
I have a couple of questions:

• I really think that this test should be run before deploying any a new version of Che. Does it makes sense to add it as a final step of our rh-che build, just before promoting the build to prod?
• Is the source code and instruction to run this somewhere? It would be nice if we could run it locally to test our commits before pushing to github.

[ldimaggi]

Hey Brad:

• The tests are here: and can be run locally - https://github.com/fabric8io/fabric8-test/tree/master/ee_tests
• James S. is already running related tests in his build process - anyone else can do this too.