When deploying CRDs to kubernetes properties aren't replaced in deployment yaml files

[marespane]

Info

• Eclipse JKube version : 1.0.2
• Maven version (mvn -v) :

Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 11.0.9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-11-oracle
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-56-generic", arch: "amd64", family: "unix"

• Kubernetes / Red Hat OpenShift setup and version : minikube latest version ( kubernetes version 1.19.4 ) and EKS cluster kubernetes v1.17.4

• If it's a bug, how to reproduce : Use my sampleKerberosProject, first apply test_resource.yaml custom resource definition, then mvn k8s:resource && mvn k8s:apply
  You will get error, which will be solved if you in src/main/jkube/test-cr.yml replace ${app_namespace} with any namespace.

I was looking into your code, and quick fix is to replace resourceDir with OutputDirectory. But probably better solution is to replace properties in getCustomResourcesFileToNameMap function.

• Sample Reproducer Project : https://github.com/marespane/sampleKerberosProject

[rohanKanojia]

Hmm, I can reproduce this. Right now, Custom Resource fragments are not part of the enrichment phase and are applied as it is during k8s:apply goal. It's being done here:

https://github.com/eclipse/jkube/blob/bf88230a5c110d686ea02ffb45dba8a294f5e2e9/jkube-kit/config/service/src/main/java/org/eclipse/jkube/kit/config/service/ApplyService.java#L455-L463

We would probably need to read file as string and replace properties with their respective values. We're doing something similar for Dockerfiles here:
https://github.com/eclipse/jkube/blob/bf88230a5c110d686ea02ffb45dba8a294f5e2e9/jkube-kit/build/api/src/main/java/org/eclipse/jkube/kit/build/api/helper/DockerFileUtil.java#L129-L135

[manusa]

#534 review meeting notes

This are some of the bullet points and actions after reviewing the approach followed in #534

1. Enricher should not be used to accomplish this functionality.

2. Custom Resources should be treated as any other resources processed by JKube (namely resource fragments)

3. The implementation of a Generic Resource was initially tried but the use of Serialization.yamlMapper().readValue() threw some exceptions.

---

I managed to implement a GenericResource that can be used to deserialize any yaml resource into a HasMetadata instance. You can check the implementation in this demo project: https://github.com/marcnuri-demo/fabric8-generic-custom-resource

What we're basically doing here is creating a very simple/basic implementation of HasMetadata that deserializes any extra fields and properties into the additionalProperties field.

In order to allow the use of this GenericResource in a KubernetesListBuilder and to allow the use of ObjectMetaBuilder visitors (e.g. ProjectLabelEnricher) a basic GenericResourceBuilder class has been implemented too. I've manually implemented this class so that we don't need to add the sundr.io dependency to generate builders. Unless I missed something else, this should be enough to provide the required functionality in JKube.

---

In order to implement the current functionality following steps should be performed:

• Port the GenericResource and GenericResourceBuilder classes to JKube
• Refactor the following method so that CRs are deserialized using the techniques shown in my example.
  https://github.com/eclipse/jkube/blob/3c4482b29259b7bc53dde121ba7fe2f1c9df73c8/jkube-kit/enricher/api/src/main/java/org/eclipse/jkube/kit/enricher/api/util/KubernetesResourceUtil.java#L146-L159
• Remove or adapt any special clauses that deal with CustomResources, since now they should be treated alongside fragments.
• Probably adapt the recently refactored apply/undeploy logic. If CR special cases can be removed, remove them and modify the entity comparator so that CRs are applied in the right order.
• Make sure that everything works

I'm not sure if we can add a list in the src/main/jkube directory, IIRC we can't. But if we can, then some additional tasks should be performed for deserialization of the CRs.