Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Product-Config 2.0

Ouverte
  • Quelque chose ne va pas ?
#362 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
rust
Domaine
backend-api-design

Piste de recherche

Commencez par l’implémentation existante de product-config et la proposition associée stackabletech/issues#198, puis comparez-les aux exemples ProductConfig derive et ProductConfigFragment de cet Issue. C’est terminé lorsque la priorité typée, les valeurs par défaut, les erreurs de validation et l’approche de sérialisation différée sont suffisamment spécifiées pour le reconciler et la hiérarchie des remplacements.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

The current product-config architecture has a few issues that we keep bumping into:

  • It's confusing to understand what values come from where
  • Validation error messages are produced in the context of the product's configuration format, which is confusing to users who configure it in term of our ProductCluster abstraction
  • PC only works on unstructured key/value maps that correspond directly to the product's configuration structure, making it difficult to feed config back from PC to the operator itself (for example: port values need to match between the configuration's listen option and the generated discovery configmaps)
    • This often leads us to bypass P-C for these options
    • We have no solid way to get back typed Rust values when using the Configuration mechanism to allow fields to be overridden across the ProductCluster/Role/RoleGroup hierarchy (without implementing the same precedence mechanism in the operator itself)
  • There is a lot of repetitive boilerplate when linking Rust structs up to the PC machinery

To work this out I propose reorient PC so that the Rust structs are the source of truth for the structure, and so that precedence rules and validations are applied while still working with typed Rust values. We would still need to serialize to the product's native configuration format (and apply overrides to that) eventually, but this would be delayed until it is required.

From the definition side, the API is currently expected to look something like this:

#[derive(ProductConfig)]
struct ZookeeperConfig {
    #[pc(default = 1000)]
    #[pc(file("hdfs-site.xml", "tick.limit.ms"))]
    tick_limit_ms: i32,
}

This would expand to something like the following:

struct ZookeeperConfigFragment {
    tick_limit_ms: Option<i32>,
}

enum ZookeeperConfigValidationError {
    NoTickLimitMs,
}

impl ProductConfigFragment for ZookeeperConfigFragment {
    type Validated = ZookeeperConfig;
    type ValidationError = ZookeeperConfigValidationError;

    fn merge(self, other: &Self) -> Self {
        Self {
            tick_limit_ms: self.tick_limit_ms.or_else(other.tick_limit_ms),
            ...
        }
    }

    fn default() -> Self {
        Self {
            tick_limit_ms: Some(1000),
        }
    }

    fn validate(self) -> Result<ZookeeperConfig, ZookeeperConfigValidationError> {
        match self {
            ZookeeperConfigFragment { tick_limit_ms: Some(tick_limit_ms) } => Ok(ZookeeperConfig {tick_limit_ms}),
            ZookeeperConfigFragment { tick_limit_ms: None, .. } => Err(ZookeeperConfigValidationError::NoTickLimitMs),
        }
    }
}

This would allow the reconciler to process already fully merged and validated ZookeeperConfig objects, while still preserving the flexibility of the override hierarchy.

Product-config YAMLs would be relegated to serving as progressive enhancements and overrides to the metadata. For example, this could be used to improve backwards compatibility with older product versions, or to supply more thorough documentation. The current proposal for these looks like this, but this part is still fairly up in the air:

mixins:
- appliesTo:
    product:
    - kafka
    versionRange:
    - product: ">=1.0.0"
    properties:
    - tick_limit_ms
  apply:
    description: |
      The maximum allowed clock skew between cluster members
    default: foo

This is a part of https://github.com/stackabletech/issues/issues/198.

Langage dominant
Rust
Étoiles
169
Forks
20
Merge moyen
1 j 19 h
PR mergées (30 j)
14

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de stackabletech/operator-rs

Toutes les issues de stackabletech/operator-rs

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.