Remove ConditionUpdater's 'removeUntouched' argument
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
Comienza localizando ConditionUpdater y sus llamadores en los controladores y las pruebas, incluidos los usos en repositorios que realizan importaciones. Elimina el interruptor removeUntouched, conservando el comportamiento que mantiene las condiciones no modificadas, y luego actualiza los llamadores y las pruebas afectados para confirmar que condiciones como C permanecen después de actualizar A, B y D.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What would you like to be added:
Currently, the ConditionUpdater takes a bool argument that specifies whether 'untouched conditions' are kept or deleted. We don't need this switch anymore. Let's remove it to simplify the code base.
Example
Let's assume the old condition list contains three conditions, with the types A, B, and C.
If the bool is false, updating A, B, and D will result in the new condition list containing A, B, C, and D.
If the bool is true, updating A, B, and D instead results in the new condition list containing A, B, and D. The condition C is removed, because it has not been touched with the latest update operation.
Why is this needed:
When the ConditionUpdater was originally implemented, the desired behavior of conditions had not been discussed, therefore the library was built to support both options.
Lately, we have not only switched to the Condition type from the k8s.io/apimachinery/pkg/apis/meta/v1 package, which contains an ObservedGeneration field that allows to identify outdated conditions, but we also decided that we don't want old conditions to be removed. Supporting both options is therefore no longer necessary.
Note
There are various controllers and other coding (e.g. tests) that currently use the ConditionUpdater with the value set to true. Removing the option (by implicitly always setting it to false) will lead to some refactoring in importing repositories.
- Lenguaje dominante
- Go
- Estrellas
- 2
- Forks
- 4
- Merge medio
- 1 d 5 h
- PR fusionados (30 d)
- 12
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de openmcp-project/controller-utils
-
Dependency DashboardAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 10/100
openmcp-project/controller-utils#20 ·
Los mantenedores suelen responder en 1 día
Todos los issues de openmcp-project/controller-utils
Issues similares
-
area:web p3
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Lets-Parley/Parley#912 ·
Los mantenedores suelen responder en 1 día
-
enhancement help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Git-Hospital/githealthcheck#61 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
afreidah/s3-orchestrator#1824 ·
Los mantenedores suelen responder en 1 día
-
Type: Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
projectdiscovery/notify#569 ·
-
internal
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día