Add Kompose support

[rhuss]

Kompose is an awesome conversion tool which creates Kubernetes descriptor objects from Docker compose files.

The idea is to extend the fabric8:resource goal to support Docker compose files via an external CLI call to kompose. This should be possible to be switched on either explicitly by a configuration option <composeFile> in the XML configuration or maybe even implicitly by monitoring a directory src/main/fabric8-kompose for the content of some docker-compose.yml files.

The flow would be:

• If enabled and present, kompose is called externally which creates Kubernetes resource descriptor yaml files in a build directory below target/fabric8. Configuration for kompose comes from the plugin configuration.
• These descriptors are read in by f-m-p via the kubernetes client
• The so instantiated KubernetesList is then used as starting point for the further processing:
  • Additional fragments can be added
  • Information of the XML configuration can add to this list
  • The enricher chain is fed with this list so that it can be enriched as usual.

An alternative approach would be to re-implement kompose functionality in Java which would provide a better integration (no external tool is required) but is much more work.

@jstrachan @pradeepto wdyt ? Is this a feasible plan ? Or do you see a better integration point ?

[jstrachan]

Sounds good to me! A few random thoughts:

• should we default to look in 'src/main/kompose/*' for the files to transform?
• the kompose-generator should have a config option of the file name /wildcard to look for compose/kompose files - then folks could just add fmp to their pom.xml and get kubernetes support even if the developer is already using compose files already - I.e. No need to move them, just point fmp at where they are

[rhuss]

Yes, that was the idea to pickup kompose files directly from src/main, like we do for fragments.
Would love to group them all under src/main/fabric8 to not pollute the src/main dir more.
We can not put it into src/main/fabric8/kompose/ though, as this would collide with auto-profile detection.

Maybe we should add an src/main/fabric8/fragments/ where we pick up fragments, too, and where profile directories can be added. I know that sounds a bit confusing (profile directories are probably not well known, but see https://maven.fabric8.io/#profiles-using for "Profiles for resource fragments". Then we are free to have sub-dir in src/main/fabric8 and we could also e.g. move src/main/fabric8-includes to src/main/fabric8/includes.

[hrishin]

<composeFile> XML configuration option looks better instead of looking into default directory. Few questions from implementation standpoint

1. Assume using kompose as conversion tool, kompose creates 'service', 'deployment' and other kubernates descriptors. Still 'resources' goal execution has to go through enrichers once kompose generate k8 descriptors?

2. Best way to make sure kompose binary availability for maven plugin?

• Let ask user to install kompose binary on host. Then need to make sure the kompose version compatibility if required.
• Package kompose binaries in mevan plugin artifact itself. I'm not sure if this is good method additionally kompose size if big.

[jstrachan]

@hrishin a few thoughts:

1. yes the enrichers should kick in unless the user disables them

2. Check the $PATH and fail if its not there? It might be worth running kompose -v or whatever to find the version and failing the build if the version number is too old?

We could get the plugin to download on the fly and install the binary; we do this with the setup goal https://maven.fabric8.io/#fabric8:setup

So maybe if the binary is not found, we could recommend to the user they install it by hand and add it to $PATH (maybe with a download URL) - we could add the binary to those installed by mvn fabric8:setup?

[hrishin]

@jstrachan thanks for confirmation, though it's mentioned in the flow :)

@rhuss

• If enabled and present, kompose is called externally which creates Kubernetes resource descriptor yaml files in a build directory below target/fabric8. Configuration for kompose comes from the plugin configuration.

Here target directory is target/fabric8 or src/main/fabric8? kindly correct me if I'm wrong, as per current implementation resources fragments are read from src/main/fabric8 by KubernetesResourceUtil.listResourceFragments(resourceDir); and default value for resourceDir is
@Parameter(property = "fabric8.resourceDir", defaultValue = "${basedir}/src/main/fabric8") private File resourceDir;
(though resourceDir paramter may be configurable)

Instead of manipulating these directories with kompose output, is it okay to create resource descriptors in temp directory? In that way we can remove it once its used .

[jstrachan]

yeah, we should change fabric8-maven-plugin to also look in some canonical directory for generated fragments by other tools like kompose/kedge. Maybe something like target/fabric8-generated?

[hrishin]

@jstrachan @rhuss
Initially I thought let's complete the basic f8-m-p<->kompose integration and then will think on setup/install kompose part.

• Check the $PATH and fail if its not there? It might be worth running kompose -v or whatever to find the version and failing the build if the version number is too old?

We could get the plugin to download on the fly and install the binary; we do this with the setup goal https://maven.fabric8.io/#fabric8:setup

So maybe if the binary is not found, we could recommend to the user they install it by hand and add it to $PATH (maybe with a download URL) - we could add the binary to those installed by mvn fabric8:setup?

I had discussion with @pradeepto as well with above points.
Yes, installing kompose binary with fabric8:setup looks convenient option from user experience stand point, indeed nice thought.
Assuming kompose is not installed, key thing is to install right binary by detecting which Operating System JRE instance is running on.
Apart from this it would be great if fabrib8:setup can take additional kompose version parameter from user, so it can help to install or upgrade the right version of kompose binary otherwise it will install the latest version of it.
Last but not least, ask user to install kompose from http://kompose.io/installation/ with version information mentioned.

sounds okay?

[rhuss]

@jstrachan I would not make it such generic. In fact I though that the Kompose handler reads the kompose.yml by calling out to kompose which creates the yaml file in some temporary directory. Then the kompose handler itself picks up the YAMLs and creates the kubernetes model objects, which are then merged into the current list (after XML configuration setup, before enrichment process).

[rhuss]

I think setting it up like gofabric8 with fabric8:setup makes sense. We already have an OS detection (as gofabric8 is also a go binary which we download with fabric8:setup)