Add support for "runtime fragments"

Since all generated resource objects end up in the artifact jars within META-INF/fabric8 they have to be independent of any concrete cluster installation (i.e. the must not contain the value of certain namespaces or private registries)

However, for fabric8:apply it make sense also to apply runtime specific objects which e.g. references also the namespace / project.

For example, consider role bindings, which contains the namespace in their values.

Build configs and Image Stream are other examples which are platform specific. These are not used during fabric8:apply but for fabric8:build and generated automatically. It would be nice if those could be enriched as well.

So I suggest introducing an extra runtime fragments directory, parallel to src/main/fabric8. E.g. a src/main/fabric8-rt. This could contain e.g. the role bindings required and they would be enriched when fabric8:apply or fabric8:build is called.

@jstrachan wdyt? I believe this is a good solution to keep separate and we can even add more fanciness when we are doing the deployment. E.g. we can introduce pre-defined variables (like ${namespace} or ${registry} which we then can put into the spots needed.

[rhuss]

@fabric8io/fmp-core-team should we pick up the discussion again ? After we have gained now some experiences over the years, I think the it’s still valid, that there are two kinds of deployment configuration: One which is independent on the target platform where the application is deployed (like deployments, services, etc.) and some which are very specific of the final cluster where the application is deployed to (best example is the “namespace”). So, should the “namespace” part of the generated resource descriptors which are stored also in the jars and distributed via Maven or should it be specified somewhere else (these kind of runtime fragments, or in the configuration for ‘fabric8:apply’). I think it should be separated.

For other things like configmaps or secrets which differ from environment to environment its similar but not so clear. I really think that configmaps should be added only as templates to the generated resources, which are filled when applied.

It’s a larger, principal discussion in which direction f-m-p should go, so I don’t expect a quick solution.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!