feature: sync related resource status independently of origin
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- go, kubernetes
- Domaine
- distributed-systems
Piste de recherche
Start by reading the related resource synchronization configuration and reconciliation entry points in the repository; the issue names no files or tests. Trace how spec direction is selected, then identify how an independent status direction could be configured and exercised. Done means status can synchronize in either direction independently of spec origin for the described cases.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Feature Description
Related resources currently synchronize their status only in the same direction as their spec.
Some use cases require the opposite behavior. For example, a related resource may be created in kcp
but reconciled by a controller in the service cluster. Its resulting status must then be
synchronized back to kcp.
The opposite case also exists with multiple providers communicating through an intermediate kcp
workspace: a resource may originate from a service cluster while its status is produced in kcp and
must be synchronized back to the service cluster.
Proposed Solution
Allow the status synchronization direction of a related resource to be configured independently
from its origin.
Alternative Solutions
Add a separate option to reverse the status synchronization direction.
Want to contribute?
- I would like to work on this issue.
Additional Context
This would support related resources whose spec and status are managed on different sides.
- Langage dominant
- Go
- Étoiles
- 25
- Forks
- 32
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Fournit un Dockerfile ou un fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de kcp-dev/api-syncagent
-
bug: default naming for local object fails on cluster-scoped published resourcesPeut-être pris @Sarthak-Shreshtha01 l’a pris il y a 15 jours. Ouvertekind/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
kcp-dev/api-syncagent#163 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
kcp-dev/api-syncagent#161 ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
kcp-dev/api-syncagent#195 ·
-
bug: failed sync controller prevents subsequent startup retriesPeut-être pris @Sarthak-Shreshtha01 l’a pris il y a 22 jours. Ouvertekind/bug
Difficulté 3/5 1-2 jours Accessibilité débutants 20/100
kcp-dev/api-syncagent#190 · 1 commentaire ·
-
bug: dangling schema in an APIExport is neither removed nor reportedPeut-être pris Une pull request liée à cette issue est ouverte ou déjà fusionnée. Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
kcp-dev/api-syncagent#188 · 1 commentaire ·
Toutes les issues de kcp-dev/api-syncagent
Issues similaires
-
ux
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
evcc-io/evcc#35605 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug report
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Les mainteneurs répondent en général sous 1 jour
-
type:bug
Difficulté 2/5 1-3 heures Accessibilité débutants 66/100
nightgauge/nightgauge#2732 ·
Les mainteneurs répondent en général sous 1 jour
-
fix below CVEsOuvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 5 jours
-
good first issue help wanted
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100