kcp
kcp copied to clipboard
kcp-dev
Define Proper Controller Author Behavior re: Connection URLs
In some future, a controller will be able to use ThingReplicationClaim to request local copies of data. We expect controller authors in that new world to hold two clients - one against their local cache and another against the shard front-proxy for live lookups and mutations.
Similarly, we have a VirtualWorkspace URL per shard, and perhaps controllers using these will also use ThingReplicationClaim. These controllers, however, cannot use one endpoint for their requests, since *-cluster LIST+WATCH is not easy to mux/demux. We need to determine the proper flows and expectation for controller authors for when the list of URLs changes, etc.
/cc @sttts @ncdc
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kcp-ci-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.