Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Cassandra: extenddb init does not fully configure extenddb

Abierto
  • ¿Algo no está bien?
#470 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
backend, database

Línea de trabajo

Start with bootstrapper.rs and cmd_init.rs, then trace the per-account keyspace creation path to find where permissions can be granted. Check the existing Cassandra initialization and configuration tests while following replication factor, datacenter, credentials, and role grants through the code. Done when init followed by serve reaches a healthy server, the role works with CassandraAuthorizer, and the two named guides remove the workarounds.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

cassandra enhancement good first issue

Following the Cassandra setup guide, extenddb init --backend cassandra does not get a user to a running server. After init, serve fails until the user hand-edits the generated config, and clusters are required to use the "allow-all" authorizer (not CassandraAuthorizer). Issues were confirmed during the review of PR #412 (Cassandra documentation), by building the branch and following the guide; the docs now describe the broken-but-real behavior. This issue tracks fixing the behavior so the docs can describe a working path.

  1. --replication-factor is read but never declared

bootstrapper.rs reads --replication-factor via extract_arg (bootstrapper.rs:77), but InitArgs in cmd_init.rs never
declares the flag. clap parses InitArgs first and rejects the flag before the bootstrapper runs:

$ extenddb init --backend cassandra --replication-factor 3 ...
error: unexpected argument '--replication-factor' found

Same class as #267 (--sqlite-path).

Fix: declare replication_factor: Option on InitArgs with #[arg(long)]. The existing bootstrapper read and the
conflict check at bootstrapper.rs:150 then work.

  1. Application credentials are written commented out

init creates the application role (extenddb / extenddb-local-dev by default), but the generated [storage.cassandra section has username/password commented out, showing placeholder values (cassandra / cassandra-password) rather than the role it created. serve then connects unauthenticated and fails:

extenddb fatal: Failed to connect to cassandra: Connection error: Connection timeout after 10s.

Setting the two fields to the role init created makes serve start and /health return healthy. PostgreSQL and MongoDB write a working connection string; Cassandra is the outlier.

Fix: write a config serve can use as-is. Options: write username/password live and uncommented set to the created
role; or reference an env var (EXTENDDB_APP_PASSWORD is already the preferred password input) from the config. Either is fine: the requirement is that init → serve works without a hand-edit.

  1. Datacenter is hardcoded to datacenter1

The bootstrapper hardcodes datacenter: "datacenter1" (bootstrapper.rs:229), writes it to the config (:694), and offers
no flag. Keyspaces use NetworkTopologyStrategy referencing datacenter1, so a cluster whose local DC has any
other name fails:

Unrecognized strategy option {datacenter1} passed to NetworkTopologyStrategy for keyspace extenddb_catalog

Fix: add a --datacenter init flag (default datacenter1), threaded to the keyspace DDL and the written config — same
path as --replication-factor (do both together).

  1. The application role is granted no permissions

init runs CREATE ROLE ... WITH PASSWORD AND LOGIN = true (bootstrapper.rs:288) but no GRANT. Under
CassandraAuthorizer, serve fails:

User extenddb has no SELECT permission on

or any of its parents

Only AllowAllAuthorizer works today.

The grant must scope to the deployment's keyspaces (catalog + per-account under keyspace_prefix). Per-account
keyspaces are created after init, and Cassandra has no wildcard/pattern grant, so grants can't all happen at init
time: the per-account keyspace-creation path must grant the role as each keyspace is made.

Fix: issue GRANT SELECT/MODIFY/... ON KEYSPACE TO at each keyspace's creation (bootstrapper
for the catalog keyspace, the per-account path for account keyspaces). Then CassandraAuthorizer is supported.

Done when

  • init
    --backend cassandra against an authenticated node, followed by serve, reaches a healthy server with no manual config edit.
    --replication-factor and --datacenter are accepted and take effect.
  • A role created by init works under CassandraAuthorizer.
  • docs/cassandra-setup.md and docs/getting-started.md are updated to drop the workarounds this issue removes.
Lenguaje dominante
Rust
Estrellas
517
Forks
60
Merge medio
2 d 23 h
PR fusionados (30 d)
25

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ExtendDB/extenddb

Todos los issues de ExtendDB/extenddb

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.