Define Proper Controller Author Behavior re: Connection URLs

[stevekuznetsov]

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

[kcp-ci-bot]

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

[kcp-ci-bot]

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

[kcp-ci-bot]

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]

@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.