Manage "Component" resource

[rhuss]

Think about an enricher which adds a Component CRD for the project at hand.

@cmoulliard do you have a link to the Component CRD specs and discussions?

[cmoulliard]

Component CRD specs

We are in the process to review it but the API should be hosted here till we will been able to move the project under k8s sig - https://github.com/snowdrop/component-api

[cmoulliard]

enricher

Think about an enricher

Will this new enricher been compatible with existing version of fmp or we should target the new openshift plugin and refactored code of fmp ? @rhuss

[cmoulliard]

for the project at hand.

Do you mean that it will be then required that the yaml file generated is then installed on k8s/OpenShift using oc create/apply -f command ? @rhuss

[rhuss]

@cmoulliard that's a good question. It depends when Component CRD will land in odo as we very likely want to reuse odo here for creating that resource.

[cmoulliard]

Component CRD will land in odo

A ticket has been created by odo and we will work on that with Suraj - redhat-developer/odo#1062

[lordofthejars]

I have been thinking about this issue and how could be initially implemented. Regarding this issue, I see two possible use cases that we could cover.

• The first one is the one implemented now in odo which is thinking of adoption of deploying to OpenShift cluster by devs, so odo is just doing all the work but without allowing ops to reuse the scripts since they are not generated.
• The second one is for odo v2. In the next version of odo you'll be able to generate the resources as a file so they can be reused also by ops team.

So obviously from the point of view of FMP we should be able to work in both modes making odo the central place for some generation/deployment and in some cases FMP enrich them.

Then to make this integration happens, we need to integrate odo CLI into Java world. I have done this in the past, concretely in three projects, and I want to share some of my experience here:

• The best way to proceed is by creating a core module that contains all the wrapping elements between the Go CLI and Java. Then we can create modules (Maven, Gradle, JUnit, Arquillian, ...) that use this wrapper module for interacting with odo, so from the point of view of these modules, they do not even know that it is implemented in Go internally.

• This core module cannot use dependencies widely used or with a history of break back compatibilities, in this category fall Jackson, Apache HttpClient, Guava, ... The reason is that Java does not isolate classpath. Libraries that work really well without affecting the transitive dependency resolution and also offers really nice nack compatibility are json-minimal, okhttp or awaitility.

• CLI tool, in this case odo must help a bit too to make our things easier. This means that should offer an option that if it is set, the output printed in the console is not generated as string messages but as a JSON documents, in this way we are able to parse the output and offer a better integration in Java ecosystem. This also applies to log lines printed in the console.

• The CLI must be installed on running machine, in case of Java it can be in classpath as well. So in my experience, the best way is to provide a JAR file containing the tool for each of the platforms supported (Mac, Linux, Win) so if this JAR is in classpath it means that we can unpack it and take the CLI tool depending on the platform we are running and use it. But also we should be able to override this with a property (system property or as a parameter in core module) that sets the home location of the tool (in our case odo) so it is always customizable.

So the very first thing we should do in FMP side is to create this core module and in case of odo provides a machine format of the output.

[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!