Migrating kuksa.val.services to eclipse-kuksa

[erikbosch]

The Kuksa project has a long term goal to migrate all assets to the https://github.com/eclipse-kuksa organization. This issue intend to cover the work and to be used for discussion. It is possible that the content of this repository may be splitted to allow for independent update of the services/tests

Current proposal:

Content	Proposed New Repo
mock_service	kuksa-mock-provider
hvac_service	kuksa-incubation (no security)
seat_service	kuksa-incubation (no security)
integration_test	kuksa-integration-test

[erikbosch]

Some thoughts/assumptions that I have:

• No interest in Dapr and Kuberneteres, so we could remove everything related to this
• Unclear if anyone is interested in VsCode/DevContainer support. I am normally not using DevContainers so if there are persons interested in keeping the devcontainers please step forward so we can include you in the discussions on what from https://github.com/eclipse/kuksa.val.services/blob/main/.vscode/tasks.json that is useful to keep. If we keep them we should better document how they can be tested.
• Do we want mock_service to become a repo if its own, like kuksa-mock-service? It could be seen as a usable tool for testing.
• The seat_service and hvac_service are more of examples and not reusable as is. Do we want to put them in a common repo kuksa-examples
• integration_test covers a little bit of everything and could be added to a common kuksa-integration-test repo. It could for main run nightly on latest version of other repos/containers, but then also be used to test and tag specific versions that are known to be compatible.
• That the oci-container (based on https://github.com/eclipse/kuksa.val.services/blob/main/tools/Dockerfile) is not needed, or at least not need to be published as a pre-built Docker container?

@SebastianSchildt @mikehaller @lukasmittag - your opinion of how to best split content would be appreciated

[mikehaller]

• +1 to remove DAPR and k8s
• Keep VSCode/DevContainer: I am interested in having the VS Code DevContainer setup kept. It's a good concept to align the setup between devs and imho we should promote to use it in the same/similar way as Eclipse Velocitas is doing it. Imho the most important part is .devcontainer/. I am not a fan of .vscode/tasks though, but that's very subjective. We'd have to split it up between the components: e.g. run the examples goes to the kuksa-example repo, the "run databroker" task is different in the kuksa-databroker repo than in the kuksa-example demo etc.. I have no idea yet how to make the vscode tasks testable though.
• +1 for moving the mock service into its own repository, agree that it might become a separate usable standalone component for development and testing reasons
• +1 for moving the example services into a separate repo
• +1 for moving integration tests into a separate repo
• No idea about the tools/Dockerfile, maybe just keep but not publish.

[erikbosch]

Thanks for the comments @mikehaller. As long as we are willing to spend the effort to at least do a sanity check on the VSCode/Devcontainer before release and have documented how to do a sanity check I have no problems keeping them.

I am thinking if one possibly should have all DevContainer stuff in the kuksa-integration-test repo. Many of the tasks are anyway based on that you specify a specific version in a config file rather than building from source.

[mikehaller]

Imho each repo should have a proper .devcontainer setup :)

[erikbosch]

Imho each repo should have a proper .devcontainer setup :)

If we want to spend the effort that is fine for me. But I guess for repos like kuksa-incubation that we want to have individual devcontainers for each subdirectory, as maintaining a common one could be impossible if they have different requirements. But for the kuksa.val.services migration I am not sure how much effort that would be required to refactor existing dev containers and then test them.

I am updating the proposal in top comment to reflect discussions in KUKSA community call; use the name kuksa-incubation without security for services and use the term "provider" for the mock as it froma functional eprspective is quite similare to for example https://github.com/eclipse-kuksa/kuksa-csv-provider

[erikbosch]

A draft for creating new repos now exist at https://github.com/eclipse-kuksa/.eclipsefdn/pull/23

Please check @SebastianSchildt @mikehaller @lukasmittag

(For the .eclipsefdn repo I keep PRs as drafts as we have agreed internally, to avoid involving the Eclipse admins at this stage)

[erikbosch]

Continuing discussion from https://github.com/eclipse-kuksa/.eclipsefdn/pull/23 here as I think it fits better here. The question is what do with the folder integration_test

There are 3 tests in the integration folder. One of them (test_feeder.py) seems to be more or less a copy of what exists in Databroker so it could be skipped, especially as it just seems to test Databroker so not really any integration. The other two are some form of integration tests as they test a combination of components, see below. But if we consider it ok that hvac_service and seat_service rely on Databroker for test purposes then we could argue that they could fit in the respective folder. A possible drawback could be that some helper code would need to be duplicated , like the large vdb_helper.py which is used to interact with Databroker.

The "integration tests" also to a big degree use the old API with querys like:

 name1 = "Vehicle.Cabin.DesiredAmbientAirTemperature"
    name2 = "Vehicle.Cabin.IsAirConditioningActive"
    alias1 = "temp"
    alias2 = "active"

    query = "SELECT {} as {}, {} as {}".format(name1, alias1, name2, alias2)

... so if we want to deprecate SQL functionality and the old proto interface we would need to rewrite parts of the tests to use the new API, and possibly the services as well, at least if we want to keep the services up to date with latest Databroker.

So I think it would be doable to not create an integration-test repo but instead split the tests on seat_service and hvac_service, but we should preferably agree on our long term plan for the tests and Databroker dependency for seat/hvac-services. Do we intend later to refactor them to use the new API only? If not, is it worth migrating them at all, or should we just "delete" them?

File	Used components	Comments
test_feeder.py	Databroker only	This file is quite similar to https://github.com/eclipse/kuksa.val/blob/master/kuksa_databroker/integration_test/test_databroker.py
test_hvac.py	hvac_service, Databroker
test_val_seat.py	seat_service, Databroker

[lukasmittag]

At least for seat service, I do think that it should be quiet easy to port to the new API. The only thing that it uses from the old one that is not present yet in the new one is the Registration feature. HVAC service I haven't used in a while/ever before. So I think HVAC service maybe can be h´just left as is and once there is a need for it again either written again or resurrected from the dead ;)

[erikbosch]

We could start with the ambition to keep the tests in the corresponding service-location, and keep refactoring to a minimum. I will update the .eclipsefdn PR.

[erikbosch]

Migration is considered finished to https://github.com/eclipse-kuksa/kuksa-incubation and https://github.com/eclipse-kuksa/kuksa-mock-provider

Not exactly everything has been migrated, some things are for now assumed to be unused or deprecated. If you miss something or something does not work please add an issue in the new repos, or here if it fits better.

This issue and this repo is proposed to be kept open until 2024-12-31, then it is proposed to be archived