-
Notifications
You must be signed in to change notification settings - Fork 3
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
Migrate from local_config
to same schema_registry
used in direct connections
#130
Comments
rhauch
added a commit
that referenced
this issue
Oct 26, 2024
## Summary of Changes Resolves #96 This adds the _initial but limited_ support for a new type of connection resources, called `DIRECT` connections, that represent a local or remote Kafka cluster and/or Schema Registry. The extension might create a direct connection to talk to a locally running CP installation, or a remote Apache Kafka cluster with a remote Schema Registry, or even a CCloud cluster with Schema Registry. The user may have to provide credentials to successfully authenticate and connect to each remote service/cluster. The direction connections are not necessarily the constructs we want to expose. It is likely that near-term versions of the VS Code extension will allow users to connect to local or remote Kafka and SR clusters, but it may also expose to users different kinds of connections that are all represented in the sidecar as direct connections. For example, maybe the VS Code extension allows users to connect to “Confluent Platform”, “Apache Kafka”, and “WarpStream” (in addition to CCloud and local AK+SR), and these might all be customized facades on top of direct connections. This is the first step in full support for direct connections, and as such only limited functionality is available in this PR: * CRUDL connection resources with `type=DIRECT`, with validation of fields for each type of connection. * A direct connection contains zero or one `kafka_cluster` object and zero or one `schema_registry` objects, allowing it to connect to a (remote or local) Kafka cluster and/or a (remote or local) Schema Registry. * GraphQL support for the Kafka cluster and SR referenced by direct connections. Once this PR is merged, the following will handled as followups to complete the support for direct connections: - #123 - #124 - #125 - #126 - #127 After that, we will have more improvements to better support Confluent Platform: - #128 Other improvements may include: - #129 - #130 - Allow direct connections to connect to Flink cluster and Kafka Connect cluster. Also, we avoided using `javax` and instead used `jakarta` imports due to the transfer of Java EE to the Eclipse Foundation, where it became Jakarta EE. The older `javax` packages within Java EE have been deprecated. Jakarta EE uses the `jakarta` namespace, which is incompatible with the legacy javax namespace. Mixing the two can cause issues. Several projects and frameworks… have already adopted Jakarta. Additionally, upgrading to Jakarta allows you to keep up with the latest changes and modernize your applications. https://github.com/jakartaee/platform/blob/main/namespace/mappings.adoc#mapping-javax-to-jakarta ## Pull request checklist Please check if your PR fulfills the following (if applicable): - Tests: - [x] Added new - [x] Updated existing - [x] Deleted existing - [x] Have you validated this change locally against a running instance of the Quarkus dev server? ```shell make quarkus-dev ``` - [x] Have you validated this change against a locally running native executable? ```shell make mvn-package-native && ./target/ide-sidecar-*-runner ```
5 tasks
update: initial support implemented |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently local connections can define the SR URL via the
local_config.schema-registry-uri
. Direct connections use a more flexible approach via the:We want to migrate local connections away from the
local_config
and instead reuse theschema_registry
structure used in direct connections.We'll do this by initially supporting either, giving the extension a bit of time to migrate and verify the
schema_registry
approach works. Then we can remove thelocal_config
mechanism.The text was updated successfully, but these errors were encountered: