Create openshift wrapper extension.

[iocanel]

I want to make Quarkus on Openshift to be as easy as possible.

Right now the user needs:

1. Add kubernetes extension
2. Add container-image-s2i extension
3. Set kubernetes.deploymmet.target=openshift

This pull request suggests an alternative aproach:

1. Add openshift extension

In other words, it provides a wrapper extension the makes it possible to deploy to openshift without additional configuration, while at the same time maintaining backwards compatibility.

[iocanel]

Just to clarify this is just a wrapper extension, all the functionality is still left to the existing kubernetes extension.

[geoand]

I added a comment about the code gen that I don't really understand

[geoand]

I personally like the idea a lot, it's definitely a +1 from me

[maxandersen]

I like this idea of 'starter-extensions' too; wondering if the approach has issues if we start have more and more of these - what happens if you add a openshift and a knative starter - which one wins ?

/cc @emmanuelbernard @tqvarnst for awareness as we discussed these things in past of various degrees.

[emmanuelbernard]

I think it makes a lot of sense. I knew at some point some umbrella extension would just profile / tune the usage of other extensions. So +1 to me. A few general comments though (I did not look at the implementation):

• we must be able to use the underlying extensions to do the same
  • my main usage is for someone to be able to swap between Kube and OpenShift deployments
• ideally an aggregator extension would just push "proposed" properties that are read by the config if it's not explicitly set by the user config. (but we don't have such framework today)
• another way is via build items that should have less priority compared to an explicit property

So +1 to the idea.

[iocanel]

• another way is via build items that should have less priority compared to an explicit property

That's exactly the approach we've taken here.

[iocanel]

I like this idea of 'starter-extensions' too; wondering if the approach has issues if we start have more and more of these - what happens if you add a openshift and a knative starter - which one wins ?

Thats' s an excellent question!

Here are some thoughts: In order to be able to perform a deployment for any platform, we have the following requirements:

1. Certain APIS to be available on the target API server.
2. A compatible container image to be available (e.g. s2i won't work with vanilla nor knative).

Now, if both of the conditions above are meet for more than one deployment target we should pickup the first one, unless the user has explicitly selected something else.

[geoand]

Added a few comments and questions

[geoand]

And some comments on the doc :)

[maxandersen]

looks really good - much simpler story in docs too.

One nice addition would be to add labels to the Deployment/Deployment Config so it will get Quarkus icon in dev console.

needs to have either app.openshift.io/runtime=quarkus or app.kubernetes.io/name=quarkus label.

details at openshift/console#4306

[geoand]

Are we good to go with this?

[iocanel]

Are we good to go with this?

I think that everything is wrapped, so I'd say yeah.

[geoand]

I'll let @maxandersen push the magic button then

[maxandersen]

Missed this. I'll try rebase it in a few hours when at desktop.

[geoand]

I rebased the PR onto master since Github UI was reporting a conflict

[maxandersen]

one open question is the status of the extension is marked stable even thuogh its new and depends on container-image that are preview. ill open separate issue for that.