Repo for Github Org Configuration

11 views
Skip to first unread message

Christoph Blecker

unread,
Jun 15, 2018, 6:58:01 PM6/15/18
to stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
Hey Steering/Arch/Testing/ContribEx,
Erick has been working on Peribolos (https://git.k8s.io/test-infra/prow/cmd/peribolos) which is going to be our long awaited tool to manage Github Org/Team membership via a repo 🎉

Two questions for the group at large:
- Are there objections from Steering/Arch around creating a new repo in the kubernetes org to house the configuration for this tool (the YAML files and such that will list all the org members, and all the all the teams)?
- Should this repo be public or private? Right now, only 308 of our 699 members opt-in to display publicly that they are members of the Kubernetes org.

While I know we strive to be public everywhere we can, I'm not sure if there might be potential concerns around having a public list of every org member, if they are a member or admin, and what teams they are a part of. All this data is already available to everyone in the org, but org membership is only visible if the individual opts in, and team membership is completely private outside of the org.

Thanks!

Christoph

Brian Grant

unread,
Jun 16, 2018, 3:55:23 PM6/16/18
to Christoph Blecker, stee...@k8s.io, kubernetes-sig-architecture, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
Yes, it can go in the Kubernetes org. 

It should be public. If GitHub had a way to require membership to be public, I would have done that. Part of the point of checking this in is to be transparent and auditable. Request for membership requires emailing a mailing list already.

--
You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To post to this group, send email to stee...@kubernetes.io.
Visit this group at https://groups.google.com/a/kubernetes.io/group/steering/.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CADx2oGGJD9EAdJ6ubOvyDE7f5a25jYH7a08O5UvwNiLmG-9Yjw%40mail.gmail.com.

Christoph Blecker

unread,
Jun 16, 2018, 5:19:25 PM6/16/18
to brian...@google.com, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
That was my initial thought, but when I was talking with Erick about it, the following possible concerns came up:
- Is there a reason someone would want to hide their membership with the Kubernetes org? Their github handle would already be in OWNERS files if they are a reviewer/approver, so I don't think so.
- Could someone be harassed in any way for having their membership in the org listed?
- This would also detail who has permissions to what.. is there any security concerns/considerations around that, or are they mitigated by the 2FA requirement?

Are any of these concerns a probable concern, and do any of them outweigh the desire for us to be completely transparent?

Also worth clarifying that when I say "private" repo, I mean "must be an org member to see, but all org members would be able to see and create PRs against it". The only procedural piece that I can see being complicated being that it would require an existing org member to create the PR to invite someone, as opposed to someone creating the PR themselves to self-nominate.

Brian Grant

unread,
Jun 16, 2018, 5:29:04 PM6/16/18
to Christoph Blecker, stee...@k8s.io, kubernetes-sig-architecture, kubernetes-s...@googlegroups.com, kubernetes-sig-testing
If they contributed to any public git repo in any way, wouldn't a record of that be public?

Christoph Blecker

unread,
Jun 16, 2018, 5:34:42 PM6/16/18
to brian...@google.com, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
Yes, it would.

Michalis Kargakis

unread,
Jun 16, 2018, 5:44:30 PM6/16/18
to Christoph Blecker, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
Is there another reason for starting with a separate repo vs test-infra since we already store there everything else assuming public is fine? 

Long-term it would be nice to see prow in its own repo decoupled from k8s config.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-testing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-te...@googlegroups.com.
To post to this group, send email to kubernetes-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-testing/CADx2oGGJD9EAdJ6ubOvyDE7f5a25jYH7a08O5UvwNiLmG-9Yjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Christoph Blecker

unread,
Jun 16, 2018, 6:02:39 PM6/16/18
to mkar...@redhat.com, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
Yes, we want to decouple the config for the tool from where the tool itself lives. The OWNERS who would do things like.. approve membership to the org (contribex), or approve membership to sig teams (the relevant sig), would be different than the test-infra tool OWNERS.

Michalis Kargakis

unread,
Jun 16, 2018, 6:16:11 PM6/16/18
to Christoph Blecker, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
FWIW you can still have separate owners with the current monorepo but in general I agree it needs to be separate so we can avoid config updates alongside the introduction of new features which causes the need for redeploying prow.

Garrett Rodrigues

unread,
Jun 18, 2018, 1:34:45 PM6/18/18
to mkar...@redhat.com, Christoph Blecker, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-sig-testing
+1 to a separate config org vs test-infra, and I think it makes sense for it to be public also, given that PRs and issue comments (and general K8s involvement) is public at the github handle level anyway.  

You received this message because you are subscribed to the Google Groups "kubernetes-sig-contribex" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-con...@googlegroups.com.
To post to this group, send email to kubernetes-s...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-contribex/CAB6D_Vf%2BBDn00snP-vZLR5AUAEtpVgaKsfUg6%2BC-GFVZdiNfZg%40mail.gmail.com.

Christoph Blecker

unread,
Jun 18, 2018, 10:30:42 PM6/18/18
to Garrett Rodrigues, mkar...@redhat.com, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-sig-testing
I’m thinking something like “kubernetes/org” for this. Open to other naming suggestions. If I don’t hear any other feedback or concerns, I’ll proceed with the public repo on Wednesday afternoon PT.

Tim Hockin

unread,
Jun 18, 2018, 11:30:56 PM6/18/18
to Christoph Blecker, Garrett Rodrigues, Michail Kargakis, stee...@k8s.io, kubernetes-si...@googlegroups.com, kubernetes-s...@googlegroups.com, kubernetes-sig-testing
That sounds ok, and we can always rename it if we need.

You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To post to this group, send email to stee...@kubernetes.io.
Visit this group at https://groups.google.com/a/kubernetes.io/group/steering/.

Joe Beda

unread,
Jun 19, 2018, 2:49:14 PM6/19/18
to Tim Hockin, Christoph Blecker, Garrett Rodrigues, Michail Kargakis, steering, kubernetes-sig-architecture, kubernetes-s...@googlegroups.com, kubernetes-...@googlegroups.com
+1 for not doing this in test-infra also.  That name always confused me for a lot of our automation.  It clearly isn't just test.

Joe

Reply all
Reply to author
Forward
0 new messages