Refactor Enricher Workflow to allow direct generation of OpenShift objects

[rhuss]

Description

The current way to support both, Kubernetes and OpenShift is, that we first create all K8s objects for kubernetes.yml and the convert them all in one step to corresponding OpenShift object for openshift.yml.

Although it worked quite well until now, this approach has now reached its limitations so that a pure 1:1 mapping is not easily possible and lead to ugly constructs and code coupling. (e.g. the creation of OpenShift specific objects for the app-catalog by the dependency enricher, which are then directly extracted by the ResourceMojo. Its a good example how leaky our abstraction became).

The suggested solution is to use a two-pass model, to create the OpenShift and Kubernetes individually by running the Enricher chain twice, with an argument PlatformMode for specifying which objects are to be created. That adds gives more flexibility and avoids the brute-force all in once conversion at the end.

Also, the enricher API can be simplified to two methods:

// Create default resources
void create(KubernetesListBuilder builder, PlatformMode mode);

// Enrich with extra information
void enrich(KubernetesListBuilder builder, PlatformMode mode);

The enrichment process then would work like:

for mode in "kubernetes", "openshift"
  builder = new ...
  for enricher in enrichers
    enricher.create(builder, mode);
  for enricher in enrichers
    enricher.enrich(builder, mode);
  writeToFile(builder, mode);

Also, for special use case like creating the app-catalog it might make sense to call the chain separately instead of relying that fabric8:resource runs before fabric8:app-catalog and doing checks in the ResourceMojo whether it runs together with other Mojos to create different descriptors (with the same file name !).

[rhuss]

We faced some issued with enricher calling the builder.getItems() method which in turn triggers a validation that obviously fails at that point in processing. The API should be redone to only allow visitor on the builder objects, so:

// Create default resources
void create(Visitable builderVisitable, PlatformMode mode);

// Enrich with extra information
void enrich(Visitable builderVisitable, PlatformMode mode);

or so.

The alternative (probably much better) is to wait for immutable model objects in the kubernetes-model.

[nicolaferraro]

Just a note. This can create backward compatibility issues, because people usually put some env settings (eg. cpu and mem limits) in the deployment.yml file, both if they are deploying on Openshift or Kubernetes. They will need to use a different descriptor for Openshift (dc.yml).

[rhuss]

@nicolaferraro agree that we should still some 'internal' conversions for resource fragments which we are used for both variations and which we already convert on the fly into each other

• Deployment and DeploymentConfig
• Namespace and Project
• ReplicatSet and ReplicationController (for OpenShift)

[nicolaferraro]

Yeah, this may be a (active-by-default) option.

[stale]

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!

[rohanKanojia]

Closed via #1521