Add k8s-infra-ci-robot as admin of github.com/kubernetes/k8s.io

[ameukam]

Ref: kubernetes/k8s.io#2191

Parf of : kubernetes/k8s.io#1394

Signed-off-by: Arnaud Meukam ameukam@gmail.com

[ameukam]

/assign @spiffxp @cblecker

[cblecker]

/hold

I am unclear about why we are adding a new org owner account. I would also like to understand the security behind this account before adding it as an org owner.

[ameukam]

/hold

I am unclear about why we are adding a new org owner account. I would also like to understand the security behind this account before adding it as an org owner.

@cblecker I'm not sure I understood your question correctly but right now access to this Github account is only allowed to members to k8s-infra-ci-robot@kubernetes.io. 2FA is enabled and the password is stored in my personal 1password account. I expect to migrate to a community-owned 1password account once kubernetes/community#3938 is done.

During Github Admin meeting of June 24, we agree to reduce the scope of this bot to only https://github.com/kubernetes/k8s.io.

[spiffxp]

@cblecker

I am unclear about why we are adding a new org owner account.

It's the wg-k8s-infra equivalent to @k8s-ci-robot, for the wg-k8s-infra instance of prow. Prow needs org owner access for the org(s) it manages (ref: https://github.com/kubernetes/test-infra/blob/master/prow/getting_started_deploy.md#github-bot-account)

We can't have two instances of prow use the same bot account, or we'll be splitting GitHub API rate limit consumption between them, which I strongly suspect will exhaust the rate limit for prow.k8s.io

We need to have two instances of prow so we can shift from one to the other gradually, vs taking a potentially unknown amount of downtime to shift prow.k8s.io over entirely

We're in the "get an instance up so we can test/pilot things against a very small number of repos" phase. So we could conceivably make the bot account an admin of just those repos we're piloting against. But it will eventually need to become an org owner.

I would also like to understand the security behind this account before adding it as an org owner.

I think @ameukam sufficiently answered this. As a followup, I would like the GitHub admin team to own k8s-infra-ci-robot@kubernetes.io, either by adding the github@kubernetes.io group as a member, adding its members directly, or changing the bot's e-mail to something like github+k8s-infra-ci-robot@kubernetes.io (though this is my least preferred option.)

[spiffxp]

Ah right, I see @ameukam already scoped it down to owner of kubernetes/k8s.io. In that case I'm going to remove the /hold but I would like an ack from @cblecker on whether his questions have been adequately answered.

[spiffxp]

/lgtm
/hold cancel

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ameukam, spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• config/kubernetes/OWNERS [ameukam,spiffxp]
• config/kubernetes-sigs/OWNERS [ameukam,spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cblecker]

@spiffxp Thanks -- you did address my questions. I still have a general thought of "are we making this more complicated than need be"?

Like, when we actually cut over, is downtime actually unacceptable?

[spiffxp]

I think we should definitely put that on the table as an option; since prow.k8s.io still hosts more than kubernetes stuff at the moment, we should consider kubernetes/test-infra#12863 on that critical path, though it looks like we've made some progress on it. There would also be a number of test-infra-oncall assumptions to unwind here.

Having a separate instance in k8s-infra will allow us to prototype and pilot migration and community on-call to understand if it's too complicated to try a gradual migration. Has OpenShift done anything like this?

tl;dr Need to scope out and plan at least these two alternatives as part of kubernetes/k8s.io#752. Given release schedule I don't see actual execution of whatever plan we choose until after v1.22 is out the door.

[nikhita]

Having a separate instance in k8s-infra will allow us to prototype and pilot migration and community on-call to understand if it's too complicated to try a gradual migration. Has OpenShift done anything like this?

@alvaroaleman in case you've done something similar before :)

[alvaroaleman]

Having a separate instance in k8s-infra will allow us to prototype and pilot migration and community on-call to understand if it's too complicated to try a gradual migration. Has OpenShift done anything like this?

We did move our Prow instance from one cluster to another about a year ago. We did have a downtime where we wouldn't start new jobs for about 4h (but still keep them, and process them after that window). We have some docs on that somewhere, I can try to find them if it helps.