-
Notifications
You must be signed in to change notification settings - Fork 107
Description
I think we should have semi-persistent "team" clusters that can last longer than default ones (but are still periodically flushed and reprovisioned) and also have a workflow where the creds can be easily shared among a team.
Even among the team, there'd still be an "owner" who might be e.g. actively testing their operator, but they'd be able to release it and e.g. turn back on the CVO and leave things hopefully a in a clean state for the next user. Or, commonly two members of a team might be concurrently working on a PR.
Another (quite common for me) use case is "I just want to run some read-only commands (as kube:admin) against a recent-ish 4.6 cluster".
Setup:
- A team is defined as one of the github team aliases we have today, e.g. @openshift/openshift-team-red-hat-coreos
- We synchronize membership of the GH team to Slack groups
UX, talking to @cluster-bot
<user> teamcluster request
<bot> cluster https://console.team-redhat-coreos.devcluster.openshift.com/ is currently available
<bot> (kubeconfig attachment)
<bot> use `teamcluster done` when you're done
Scenario where cluster is in use:
<user> teamcluster request
<bot> cluster https://console.team-redhat-coreos.devcluster.openshift.com/ is in use by @miabbott
<bot> use `teamcluster ping` to send a message to @miabbott requesting current credentials
<user> teamcluster ping
Bot to @miabbott:
<bot> user @cgwalters has requested access, reply "yes" to grant, "no <reason>" to indicate refusal
<miabbott> <yes or no>
Alternative flow for immediate grant of "readonly" access:
<user> teamcluster request ro
<bot> cluster https://console.team-redhat-coreos.devcluster.openshift.com/ is in use by @miabbott
<bot> (kubeconfig attachment)
<bot> You requested read-only access, please avoid changing the cluster
(Bot also ends a message to @miabbott like: <bot> User @cgwalters requested readonly access)