make configuration generation recovery safe after failed apply and rollback

Abierto
  • ¿Algo no está bien?
#1,841 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
networking

Línea de trabajo

Read ConfigProcessor::apply, rollback, and apply_gw_config in mgmt/src/processor/proc.rs together with PipelineData and the flow validity checks in pipeline/src/pipeline.rs, flow-filter/src/lib.rs, and acl-filter/src/lib.rs. First reproduce the staged-generation and failed-rollback sequence described in the issue, inspecting counters, tables, and flow stamps. Done means partial installation and rollback have a defined safe recovery behavior, including concurrent flow creation and later successful apply.

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

Descripción

bug

Follow-up to PR #1762, specifically the failed-apply generation review comment.
Deferred for separate investigation and implementation.

PipelineData separates the generation enforced by the pipeline (genid) from the generation stamped onto newly created or revalidated flows (staging).
Configuration application opens the new staging generation before migrating flows, then enforces it after the configuration is successfully applied.
This lets flows created during a successful apply survive its completion.

The failure path needs a defined recovery contract.
apply_gw_config() calls open_generation() before fallible port-forwarding and router configuration operations.
A later error can leave staging ahead of the enforced generation.
apply() attempts rollback by reapplying the previous configuration, but rollback can also fail before resetting staging.
Rollback errors are logged, and packet processing continues.

Successful rollback normally restores both generation counters and reruns flow migration.
However, merely resetting staging on an error would not address flows already created or migrated into the failed generation, nor undo partially installed tables.
Generation checks accept active flows whose generation is greater than or equal to the enforced generation; the flow filter can therefore continue trusting their cached destination without revalidation.
The packet-level consequences depend on which tables were installed and which recovery steps completed.

This concern is supported by code inspection.
A reproducible traffic test is still needed; no packet-level failure has been demonstrated for this ticket.

An initial reproduction should exercise this sequence:

  1. Start with configuration generation G fully applied.
  2. Begin applying G+1 and allow open_generation(G+1) and flow migration to run.
  3. Create traffic that installs flows while G+1 is staging.
  4. Inject a router configuration failure before set_genid(G+1).
  5. Inject a rollback failure before rollback reaches its generation reset.
  6. Inspect both counters, installed tables, and flow stamps, then send forward and return traffic through the surviving flows.

The recovery design should answer how traffic is handled during partial installation and failed rollback, how flows from an abandoned apply are invalidated or revalidated, and how a later successful apply restores a coherent state.
It must account for concurrent flow creation while recovery or migration walks are running.
Restoring a counter alone is not a complete recovery mechanism.

Relevant code, pinned to the reviewed PR revision:

Lenguaje dominante
Rust
Estrellas
21
Forks
9
Merge medio
3 d 16 h
PR fusionados (30 d)
104

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 githedgehog/dataplane

Todos los issues de githedgehog/dataplane

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.