Maintenance mode stacking support

Abierto
#3,041 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@LZD-PratyushBhatt ya está trabajando en esto.

Desde el 19/5/2025.

  • #4 de @LZD-PratyushBhatt — abierto
  • #3044 de @LZD-PratyushBhatt — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
java

Línea de trabajo

Localiza la implementación del modo de mantenimiento y sigue cómo se escribe, elimina y expone simpleFields.REASON a través de la API de mantenimiento. Revisa primero el manejo de znode y el comportamiento existente de legacy-client. Se considera terminado cuando varios actores pueden añadir y eliminar motivos independientes, el clúster permanece activo mientras exista algún motivo y simpleFields.REASON refleja el motivo activo más reciente.

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

Descripción

The current implementation of maintenance mode for clusters supports only a single reason at a time, tracked using the simpleFields.REASON key. This restricts the functionality to a single actor and reason, which limits flexibility and coordination.

This proposal introduces a new design that allows multiple actors to independently place a cluster into maintenance mode for different reasons. We will extend the maintenance mode design to support multiple actors, each capable of independently adding or removing their own maintenance reason. The cluster will remain in maintenance mode as long as at least one active reason exists. Each reason will be associated with metadata such as the actor, reason, and timestamp. For backwards compatibility, the existing simpleFields.REASON will be retained and updated to reflect the most recent active reason. If a reason is removed, it will be replaced with the next most recent one. While legacy clients that remove the entire znode cannot be completely prevented, we will handle such cases gracefully and recommend migrating to an updated API that enables proper multi-actor maintenance handling.

Lenguaje dominante
Java
Estrellas
505
Forks
258
Merge medio
4 d 20 h
PR fusionados (30 d)
3

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una 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 apache/helix

Todos los issues de apache/helix

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.