Dedicated helm chart for the Dataplane only?

[florianrusch-zf]

As the discussion area is not available in this repo, I apologise for starting a discussion here.

I am currently looking at the knowledge agent as we as ZF want to provide this in relation to a Catena-X/Tractus-X use case. As far as I understand, the knowledge agent magic is contained in an EDC extension which is to be placed in the dataplane. As I like decoupled systems, I would now expect there to be a helm chart that just provides an additional dataplane that can simply be installed alongside an already installed EDC in K8s. Looking through the Helm Charts provided, I only found copies of the tractusx-edc helm charts with some additional values added for the knowledge-agents. Why was this approach taken? This approach does result in the knowlege-agent team having to painstakingly adopt the changes of the tractusx-edc helm chart for each new tractusx-edc release, doesn't it?

Regarding my expectation I would think of something like the following:

flowchart TB
    subgraph tractusx-edc Helm Chart
        Controlplane-->Dataplane
    end

    subgraph KA Helm Chart
    KA-Dataplane --> Controlplane
    end

Loading

And of course, for a simple all-in-one setup, you could also consider having the tractusx-edc helm chart as a dependency in the knowledge-agent helm chart:

flowchart TB
    subgraph KA Helm Chart
        subgraph tractusx-edc Helm Chart
            Controlplane-->Dataplane
        end
    KA-Dataplane --> Controlplane
    end

Loading

What do you think about these points? Maybe in this issue we could collect all the necessary steps that would allow such a simple and easy setup, and/or of course other possible ways to avoid copying and pasting code from other projects that needs to be done manually.

[drcgjung]

That is a great idea (especially it would allow us to become a part of the standard 23.09 umbrella)

Only problem is that the dataplane needs to be "statically" registered in the control plane (so the dependency is somehow bidirectional).

I think the umbrella-umbrella approach could suffer from having to move some of those intricacies out of the templates into the values.yaml

But I learned that registration at the control plane could also be done via an API call at runtime, so maybe a kind of startup action/container could help with that ...

[drcgjung]

eclipse-tractusx/sig-release#202