feature: sync related resource status independently of origin
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- go, kubernetes
- Bereich
- distributed-systems
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Go
- Sterne
- 25
- Forks
- 32
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus kcp-dev/api-syncagent
-
bug: default naming for local object fails on cluster-scoped published resourcesEvtl. vergeben @Sarthak-Shreshtha01 hat das vor 16 Tagen übernommen. Offenkind/bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
kcp-dev/api-syncagent#163 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
kcp-dev/api-syncagent#161 ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
kcp-dev/api-syncagent#195 ·
-
bug: failed sync controller prevents subsequent startup retriesEvtl. vergeben @Sarthak-Shreshtha01 hat das vor 23 Tagen übernommen. Offenkind/bug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 20/100
kcp-dev/api-syncagent#190 · 1 Kommentar ·
-
bug: dangling schema in an APIExport is neither removed nor reportedEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
kcp-dev/api-syncagent#188 · 1 Kommentar ·
Alle Issues in kcp-dev/api-syncagent
Ähnliche Issues
-
Headerless responses block while skipping duplicate status linesEvtl. vergeben @mynhe hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
projectdiscovery/rawhttp#554 ·
-
stage-fail
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
siyuan-note/bazaar#2447 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 80/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
superplanehq/superplane#9120 ·
Maintainer antworten meist innerhalb von 1 Tag