Proposal for splitting of KUKSA.val

There is a new Github organization eclipse-kuksa. Over time it is proposed that content in this repository shall be moved to one or more new repositories in the new organization. This page proposes a possible split

General idea

• Create one repo kuksa-common where we put artifacts that typically are shared, *.proto, VSS-data in JSON format, JWT example tokens, example TLS keys/certs. Applications (Broker, Server, Feeders/Providers, Services) in other repos can then decide if they want to include kuksa-common as submodule or clone wanted version as part of the build process, or if necessary just copy the relevant files
• Create one repo kuksa-doc for general documentation on the KUKSA.val solution. Like general security concept, deployment concept, and so on. Shall as much a possible refer to more detailed information in other repositories
• Create one repo kuksa-testfor integration tests

This would give a logical dependency grpah like below:

flowchart LR
    kuksadoc[kuksa-doc]
    kuksatest[kuksa-test]
    kuksacommon[kuksa-common]
    databroker[kuksa-databroker]
    client[kuksa-client]
    dbcfeeder[kuksa-dbcfeeder]
    gpsfeeder[kuksa-gpsfeeder]
    databroker-->kuksacommon
    client-->kuksacommon
    dbcfeeder-->client
    gpsfeeder-->client
    dbcfeeder-->kuksacommon
    gpsfeeder-->kuksacommon
    kuksadoc-->client
    kuksadoc-->databroker
    kuksadoc-->kuksacommon
    kuksadoc-->dbcfeeder
    kuksadoc-->gpsfeeder
    kuksatest-->client
    kuksatest-->databroker
    kuksatest-->kuksacommon
    kuksatest-->dbcfeeder
    kuksatest-->gpsfeeder
    kuksadoc-->kuksatest

Loading

Suggested Move

Folder	Suggested new repo	Comment / Used By
data/vss-core	kuksa-common
doc	kuksa-doc	Only general and basic information, detailed documentation for applications shall exist in the same repo as the application
jwt	kuksa-common
kuksa_databroker (except *.proto)	kuksa-databroker
kuksa_databroker (*.proto only)	kuksa-common
kuksa-client	kuksa-python-client	Add python to name to separate from other clients?
kuksa-val-server	kuksa-val-server	Seb: Might not migrate it at all, just archive at old position?
Kuksa_apps (s3)	kuksa-s3-app	Or do we want to see this as a service, e.g. kuksa-s3-service
Kuksa_apps (node red)	kuksa-node-red-app	Or do we want to see this as a service, e.g. kuksa-node-red-service: Seb:Might potentially into kuksa-viss when adapted to databroker (I do think we will only do the websocket thingies there, as that is possible with vanilla node.red, GRPC would mean writing cusotm nodejs modukes). Maybe have legacy in val-server
kuksa_go_client	kuksa-go-client
proto	kuksa-common
test	kuksa-test	Repo for general integration tests involving multiple components

Things to decide

• Do we want separate repos for JSON, certificates, proto or a joint one?

Strategy for moving

1. First create new repos for content that are shared by multiple applications like Proto files, example certificates. At this time do not delete anything from this repo
2. Start moving applications. When CI works for the component in the location add a prominent "deprecation" note in corresponding READMEs in this repo.
3. Move strategy is by taking a snapshot of latest master/main, i.e. old tags will not be moved. The new repos shall be refactored to use Proto/VSS/JWT from shared repo rather than from local copies
4. Keep the old repo (i.e. this repo) open for 6 months for critical bug fixes (if any) and or backports of new functionality. This is to give downstream projects some time to move to the new structure
5. After 6 months put this repo in read-only-mode