-
Notifications
You must be signed in to change notification settings - Fork 57
Che 7 devfile import via factory does not work #1488
Comments
You are likely right that it's something fixed in RC2/3; which version are you running on local minishift? The error message is in line with that; we changed devfile |
My Che version in minishift is pretty fresh:
|
I'm predicting fixed by #1474 rolling out to prod. |
@nickboldt going to close this one since devfile schema on prod-preview (rc3) and prod (rc1.1) are different and not compatible. Could you please verify that the flow with devfile works correctly on https://che.prod-preview.openshift.io/dashboard/ ? |
Regarding https://che.prod-preview.openshift.io/dashboard/, there is issue #1491 |
@ibuziuk I can't seem to log in... ... but if you open this link you can see if it loads or not: https://che.prod-preview.openshift.io/f?url=http://paste.awesom.eu/raw/DN7J |
@nickboldt You're probably logged in with your prod account. If you have a preview account as well, you could try logging in in an private browsing session. Testing your link, however, gives me the error
|
@nickboldt Same issue. I pulled the stacktrace out of the logs:
I'm still optimistic that it's an rc-3 issue; I'm working on getting ready for rc-4 today. |
@amisevsk hm... it is pretty weird - I would expect that the same devfiles would work correctly on both rc-3 and rc-4 (it is expected that they would not work on rc 1.1). Does it mean that there were some incompatible changes in devfile schema recently ? cc @skabashnyuk |
yes. rc.1.1 and rc-4 are not compatible. because of eclipse-che/che#13490 in this commit eclipse-che/che@caae00e provided devfile not working on rc1 but working on rc-4 |
@skabashnyuk sure it is expected that |
…erInterceptor' to avoid failures of workspaces started from devfile Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
Tested against dev cluster and now the workspace created from the devfile [1] fails with quota issue I believe this is a separate issue that I have already raised in the upstream in the context of eclipse-che/che#13832 (comment) [1] https://github.com/eclipse/che-devfile-registry/tree/master/devfiles/java-web-spring |
…o avoid failures of workspaces started from devfile Signed-off-by: Ilya Buziuk <ibuziuk@redhat.com>
FWIW I just tested @nickboldt's devfile links on the
I updated the https://raw.githubusercontent.com/eclipse/che-devfile-registry/master/devfiles/java-web-spring/devfile.yaml devfile to use Currently, the allocations are |
(To be clear, the same issue will occur with the devfile in our current registry) |
@amisevsk I have created a separate issue for quota related issue in the upstream - eclipse-che/che#13969 |
@amisevsk if you want to test a lower-footprint devfile, try https://raw.githubusercontent.com/eclipse/che/master/devfile.yaml for the "che-in, che-out" experience. :D |
@nickboldt "lower-footprint" is subjective, I suppose -- the Che-in-Che devfile requests 5Gi memory for the dev-machine :) rc-4.0-SNAPSHOT does at least create the resources (they don't start due to quota) |
@nickboldt Both of those worked, even though I accidentally used |
Issue problem:
This might be a dupe of #1347, but I tried to do:
https://che.openshift.io/f?url=https://raw.githubusercontent.com/eclipse/che-devfile-registry/master/devfiles/java-web-spring/devfile.yaml
and instead of a new workspace, I get:
Meanwhile in my local minishift, I can do this:
http://che-che.192.168.99.112.nip.io/f?url=https://raw.githubusercontent.com/eclipse/che-devfile-registry/master/devfiles/java-web-spring/devfile.yaml
and voom, I get a workspace:
So it's not the devfile that's at fault. Perhaps the https curl is failing to follow any http redirects (eg., http 302 code) or can't handle the ssl?
Similar experiment fails the same way:
devfile: http://paste.awesom.eu/raw/DN7J (pasted from https://github.com/eclipse/che-devfile-registry/blob/master/devfiles/java-web-spring/devfile.yaml as a raw / non-html paste)
factory load: https://che.openshift.io/dashboard/#/load-factory?url=http:%2F%2Fpaste.awesom.eu%2Fraw%2FDN7J
result:
So it's not https or curl.
Could it be that you've still got the old factory runtime in rh-che? I think this might have been fixed in RC2 or RC3... ?
Red Hat Che version:
version: 7.0.0-RC-1.1 (latest as of 2019-07-19 11:30 GMT-4)
Reproduction Steps:
see above.
Runtime:
runtime used:
minishift version
)oc version
)The minishift I'm using is v1.34.1+c2ff9cb. But I only see the factory failure on che.openshift.io.
The text was updated successfully, but these errors were encountered: