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

Can we offer a migration story for Kafka topics? #1195

Open
2 tasks done
nscuro opened this issue Apr 13, 2024 · 0 comments
Open
2 tasks done

Can we offer a migration story for Kafka topics? #1195

nscuro opened this issue Apr 13, 2024 · 0 comments
Labels
enhancement New feature or request p3 Nice-to-have features size/M Medium effort spike/research Requires more research before implementation

Comments

@nscuro
Copy link
Member

nscuro commented Apr 13, 2024

Current Behavior

For database migrations, we are in a very good spot due to the usage of Liquibase.

However, it's a different story for Kafka topics. We currently create them using a bash script, which we mount into the redpanda-init container.

This of course only works for self-hosted setups, and currently only works for Redpanda, but not Apache Kafka.

Proposed Behavior

I am wondering if we can offer a functionality that is similar to how we do database migrations.

Is it viable to implement a migration functionality that:

  • Checks for required topics on startup
  • Either:
    • Fails when topics are missing, or
    • Creates missing topics instead
  • Checks for topics that were once required but no longer are, and either:
    • Deletes them automatically, or
    • Logs a warning to notify operators about it

And if so, can / should this be done in only a single component (i.e. API server), or should each component take care of its own topics?

Checklist

@nscuro nscuro added enhancement New feature or request p3 Nice-to-have features size/M Medium effort spike/research Requires more research before implementation labels Apr 13, 2024
nscuro added a commit to DependencyTrack/helm-charts that referenced this issue Jun 12, 2024
This is still a temporary solution for until the services are able to set up topics on their own (DependencyTrack/hyades#1195).

For the moment we just want to reduce duplication.

Signed-off-by: nscuro <[email protected]>
nscuro added a commit to DependencyTrack/helm-charts that referenced this issue Jun 12, 2024
This is still a temporary solution for until the services are able to set up topics on their own (DependencyTrack/hyades#1195).

For the moment we just want to reduce duplication.

Signed-off-by: nscuro <[email protected]>
nscuro added a commit to DependencyTrack/hyades-apiserver that referenced this issue Oct 3, 2024
Adds a new init task that creates all required topics using their respective default configuration during startup.

This replaces the need for a separate init container (i.e. `redpanda-init` in our `docker-compose.yml`: https://github.com/DependencyTrack/hyades/blob/008c3a1b024969a159de085d5ca6b464147faa9a/docker-compose.yml#L251-L273).

The creation of topics is also faster because it can be done in a single batched request, vs. 10s of repetitive CLI invocations.

This init task is disabled by default for now, since it's not meant to be used for production deployments. The idea is to build on this work, and allow users to customize the default topic configurations (e.g. via env vars or config files).

Relates to DependencyTrack/hyades#1195

Signed-off-by: nscuro <[email protected]>
nscuro added a commit to DependencyTrack/hyades-apiserver that referenced this issue Oct 17, 2024
Adds a new init task that creates all required topics using their respective default configuration during startup.

This replaces the need for a separate init container (i.e. `redpanda-init` in our `docker-compose.yml`: https://github.com/DependencyTrack/hyades/blob/008c3a1b024969a159de085d5ca6b464147faa9a/docker-compose.yml#L251-L273).

The creation of topics is also faster because it can be done in a single batched request, vs. 10s of repetitive CLI invocations.

This init task is disabled by default for now, since it's not meant to be used for production deployments. The idea is to build on this work, and allow users to customize the default topic configurations (e.g. via env vars or config files).

Relates to DependencyTrack/hyades#1195

Signed-off-by: nscuro <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request p3 Nice-to-have features size/M Medium effort spike/research Requires more research before implementation
Projects
None yet
Development

No branches or pull requests

1 participant