[feature] Move the @Link annotation to a separate maven module

[cmoulliard]

Feature request

Move the @link annotation to a separate maven module. Why : As a link represents a relation which exists virtually between a component and an endpoint or service, then it should be used as standalone Annotation like the ServiceCatalog to describe such METADATA to be injected within the Component target (= DeploymentConfig)

[cmoulliard]

One prereq is to validate that we could display infos as described here

kubectl get application/my-app-1

NAME              TYPE      FRAMEWORK     VERSION        SERVICE        target
backend           runtime   spring-boot   1.5.16         -              -
frontend-sb       runtime   spring-boot   1.5.16         -              -
frontend-nodejs   runtime   nodejs        0.8            -              -
database          service   -             9.6            postgresql-db
endpoint-backend  link      -             -              -              frontend-sb, frontend-nodejs
upload            job       spring-boot   1.4.14         -              -

[geoand]

Could you elaborate a little more please?

I don't see how the comment is relevant to the ticket.

[cmoulliard]

For the moment, the operator handles Component CRD as defined here and checks if it contains within the .spec section of the ComponentSpec a Link or Runtime or Service to be instantiated on the platform.

then, when we issue this query oc get cp, we will fetch all the Components deployed on the platform

e.g

 oc get cp
NAME               RUNTIME       VERSION   SERVICE         TYPE      CONSUMED BY   AGE
fruit-backend-sb   spring-boot             postgresql-db                           3h
fruit-client-sb    spring-boot                                                     3h

If now, we manage the Link outside of the Component CRD, then we must verify that we should be able to generate such output without the need to do oc get components followed by oc get links ...

NAME               RUNTIME       VERSION   SERVICE         TYPE      CONSUMED BY   AGE
fruit-backend-sb   spring-boot             postgresql-db                           3h
fruit-client-sb    spring-boot                                                     3h
fruit-endpoint-sb                                       fruit-client-sb        

I created a project and we can't aggregate results into one table unfortunately but nevertheless we can create distinct CRDs

[geoand]

OK, so there is something I am missing I think :)

At the moment, there is no distinct Link CRD is there? Is this task about providing the ability generate the yaml for such a Link and have it saved as a separate file - thus completely removing the link information from the Component CRD?
If there is such a Link CRD, could you please point to it?

In any case, I see that the comment makes perfect sense, but I don't believe it has to do with ap4k, but with the implementation of the operator itself.

[cmoulliard]

Link CRD is there?

Correct. There is a Link type defined within the component operator but it is not yet part of an dedicated API and CRD = k8s resource having a spec, ...

[cmoulliard]

link information from the Component CRD?

This is the idea as the Link represents a relation between ComponentA and ComponentB or by example a ComponentA and a Service, ...

[cmoulliard]

I don't believe it has to do with ap4k, but with the implementation of the operator itself.

We need to package it at least as a separate maven module as it will be handled as a separate annotation such as ServiceCatalog

[geoand]

I don't believe it has to do with ap4k, but with the implementation of the operator itself.

We need to package it at least as a separate maven module as it will be handled as a separate annotation such as ServiceCatalog

Yes of course, I meant that the comment of the output doesn't have an affect on this task

[geoand]

link information from the Component CRD?

This is the idea as the Link represents a relation between ComponentA and ComponentB or by example a ComponentA and a Service, ...

So in that case, could you please provide some examples of what you think the Link annotation would look like and what it would produce as it's yaml result?

[cmoulliard]

I have updated the ticket published on k8s sig-cli as this is really blocking for the moment to use separate CRDs as we can't (like in SQL) create a query able to group the results
--> https://groups.google.com/forum/#!topic/kubernetes-sig-cli/_OOguy8NU-c

[cmoulliard]

So, I propose to wait the result of my investigations before to work on that issue @geoand

[geoand]

Yes, that makes sense :)

[geoand]

I have updated the ticket published on k8s sig-cli as this is really blocking for the moment to use separate CRDs as we can't (like in SQL) create a query able to group the results
--> https://groups.google.com/forum/#!topic/kubernetes-sig-cli/_OOguy8NU-c

Thanks for sharing!

[geoand]

I believe I have understood the basic of ap4k development, so if/when we decide to move this forward, I'd be glad to start writing code

[cmoulliard]

Ideally oc get or kubectl get should offer what we can do in SQL such as "SQL JOIN -> https://goo.gl/6j4Pue"

[geoand]

That would be cool but I am guessing it could get pretty expensive on the server side

[iocanel]

@cmoulliard is this still relevant?

[metacosm]

This isn't relevant anymore as there is no Link CRD anymore in halkyon.