Revisit boosters marked with runsOn:none

[gastaldi]

Some boosters are marked to be runsOn: none, when in fact they work with Launcher (we tested the Vert.x SSO [1] and it works)

[1] - https://github.com/fabric8-launcher/launcher-booster-catalog/blob/master/vert.x/community/rest-http-secured/booster.yaml#L4

[gastaldi]

@fabric8-launcher/runtime-fuse @fabric8-launcher/runtime-golang @fabric8-launcher/runtime-node-js @fabric8-launcher/runtime-spring-boot @fabric8-launcher/runtime-thorntail

[geoand]

What is the idea behind runsOn: none? Sorry, I have never seen that before

[gastaldi]

@geoand here are the known values: https://github.com/fabric8-launcher/launcher-booster-catalog#common-values-for-runson

[geoand]

So just looking at the booster I don't see why its runsOn value would be any different than what crud uses.
I see that is works in our CI environment (CircleCI that uses oc cluster up) just fine.

[gastaldi]

@geoand that makes sense. As a side note, the value for CRUD needs to be revisited: #324

TLDR; the starter clusters had a small quota and now they are bigger

[geoand]

👍 I always had a terrible time with any hosted openshift cluster, so I doubt I'll be able to test it

[Ladicek]

Requires creating the .openshiftio stuff, but other than that, I don't see why not.

[quintesse]

Btw, except for boosters that can really run nowhere without manual intervention (like for example the ISTIO boosters) we should always prefer "local" over "none". With "local" you will at least be able to deploy them to your local minishift or whatever you have running locally. Good for testing / demoing purposes.