Config overrides at more granular levels
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- go
- Área
- backend-api-design
Línea de trabajo
The issue names no files, tests, or code entry points. Start by locating where deployment-level configuration is defined and how tenant and destination settings are represented; then identify which settings should support overrides and how precedence should work. Done means the intended override scope and behavior are agreed on, but the issue does not specify them.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Is your feature request related to a problem? Please describe.
Not related to any particular problem.
Describe the solution you'd like
Currently, most of available configuration is managed at the deployment level (e.g. retries, timeouts, etc.). However, as we look more towards a multi-tenant world, enabling more granular configuration would be invaluable and give users more flexibility per tenant.
With that in mind, adding configuration (where applicable) overrides at the tenant and destination level will enable better support for a larger user base.
Describe alternatives you've considered
In theory, we could do multiple deployments of Outpost (per tenant), but this seems to defeat the purpose of the multi-tenancy support that Outpost has.
Happy to discuss other suggestions too!
- Lenguaje dominante
- Go
- Estrellas
- 1.1k
- Forks
- 70
- Merge medio
- 1 d 19 h
- PR fusionados (30 d)
- 54
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 hookdeck/outpost
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
hookdeck/outpost#1117 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de hookdeck/outpost
Issues similares
-
validateDeclaredPath lets control characters through into the Gradle init script's Groovy literalAbiertoagent-butler-finding agent-research bug ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
jordansmall/spindrift#5821 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
apache/rocketmq-dashboard#7243 ·
Los mantenedores suelen responder en 3 días
-
Missing example coverage: getClockPosiblemente ocupada @camunda-sdk-automation la tomó hoy. Abiertonew-operations
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
camunda/orchestration-cluster-api-go#75 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
praetorianer777/Stator#465 ·
Los mantenedores suelen responder en 1 día