Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changing submodule reference to use new repo #23

Merged
merged 1 commit into from
May 3, 2024

Conversation

erikbosch
Copy link
Contributor

@erikbosch erikbosch commented Apr 3, 2024

Use proto files from kuksa-databroker instead of kuksa.val

This should not make any practical difference as the files as of today should be identical

@erikbosch
Copy link
Contributor Author

Hmm, noticed that test fails as

  • Kuksa Server JWTs does not exist in kuksa-databroker or kuksa-common
  • Kuksa TLS certs exists in kuksa-common, but we have previously discussed if we should remove them as "default"

We have said that KUKSA Server shall reach EoL 2024-12-31, but we have not yet said when we should remove KUKSA Server support from kuksa-client. I see some options:

  • Remove default certs/tokens from kuksa-client. This we have talked about before as a preferred solution.
  • Continue to use kuksa.val as that is the only place that contains default tokens for KUKSA Server (Default TLS certs exist in kuksa-common as well)
  • Skip submodule dependency and instead use copy/patse

Thoughts @SebastianSchildt ?

@erikbosch erikbosch marked this pull request as draft April 10, 2024 08:10
@SebastianSchildt
Copy link
Contributor

Not sure what the best course of action is, but I thing removing support in python-sdk for val-server could be done immediately, as we still do have released, working versions for val-server out.

The only point is, that this library also works with the VISS "dialect" of databroker, but going forward, I don"t think supporting VISS and GRPC in one library makes sense (especially since API differences can not be hidden, and the current "threaded" API, supporting both, is an ugly compromise). So I would not hink it is worthwhile t kepp that ability (as for "VISS", rather make a nice Node.red Flow in incubation, or see whether the COVESA CSDP webclient works)

@erikbosch
Copy link
Contributor Author

So then it seems @SebastianSchildt that there is no problem to start by removing default TLS/Token, then we can as a second step decide if we should remove Websocket support or not

@erikbosch erikbosch force-pushed the erik_subm branch 2 times, most recently from c7379a3 to 9711e0b Compare April 29, 2024 14:04
@erikbosch
Copy link
Contributor Author

Updated now but should do some more tests

@erikbosch
Copy link
Contributor Author

I have tested pypi package and docker containers, things seems to work. Work might be required in downstream projects if they in test or documentation rely on that tokens/keys/certificates are available locally and default values exist.

Copy link
Contributor

@SebastianSchildt SebastianSchildt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Did some manual checking with latest databroker, seems to work lgtm 🤵

@SebastianSchildt SebastianSchildt merged commit bfa9205 into eclipse-kuksa:main May 3, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants