Giters

kubernetes / steering

The Kubernetes Steering Committee

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

kubernetes.io Google Workspace automation

spiffxp opened this issue · comments

commented

Problem Statement

Lack of API access to our existing googlegroups.com infrastructure is creating entirely too much toil (ref: kubernetes/community#3541). Some specific examples that come to mind:

  • ensuring community docs aren't stranded when original owners move on from the project
  • managing community mailing lists
  • managing calendar invites
  • using mailing list membership as one method of SIG membership (ref: kubernetes/community#5854)

In addition, lack of easily available API access to our kubernetes.io Google Workspace is preventing wg-k8s-infra from accomplishing a few tasks:

Proposed Solution

I would like to scope out and propose a solution that involves wg-k8s-infra taking on ownership and administration of the kubernetes.io GSuite instance, with appropriate tools and automation to provide as much PR-based self-service as possible.

Some items I would propose to address sooner vs. later:

  • granting wg-k8s-infra gcp org admins super-admin privileges on the kubernetes.io Google Workspace
  • a migration plan for moving mailing lists from googlegroups.com to kubernetes.io

To help me do this, I would like to start by requesting an account wg-k8s-infra-admin@kubernetes.io with super admin privileges, equivalent to the access held by the scN@kubernetes.io accounts that currently manage the kubernetes.io Google Workspace. This will allow me to create 1-2 other accounts to use as pilots, as well as the ability to grant them appropriate API access. AFAICT there is a one-to-one mapping between Google Workspace users and service accounts they delegate to, but if not, I'm happy to stick to 1 user.

As proof that I'm not asking for cart-blanche, I have an old not-fully-formed proposal I started putting together back in March 2021. Based on feedback I gathered while shopping it around privately, I don't consider it ready for review, but it can give you an idea of where I am thinking of heading.

Cost

Based on back-of-napkin numbers I was running in March, I could be asking for something in the ballpark of O($100/yr) best-case, to O($30k/yr) worst-case. It seems highly unlikely that worst-case costs would be necessary. It was unclear to me whether this was coming out of the GCP Credits donated to wg-k8s-infra, or out of CNCF directly.

Open Questions

  • What is the actual concrete proposal?
  • What is the proposed timeline?

Next Steps

  • Provision a wg-k8s-infra-admin@kubernetes.io account that @spiffxp can use to pilot/trial appropriate API access
  • Draft a concrete proposal with at least two alternatives and cost options
  • Get approval to move forward

Other Considerations, Notes, or References

/committee steering
/wg k8s-infra
/sig contributor-experience
/priority important-longterm

commented

/assign @dims @mrbobbytables @parispittman
To help out with the "requesting an account wg-k8s-infra-admin@kubernetes.io with super admin privileges, equivalent to the access held by the scN@kubernetes.io accounts" piece

EDIT: I plan on being the sole holder of these credentials as a steering emeritus, until I can identify less privileged levels of access that steering is comfortable delegating beyond myself

commented

/approve

yes, let's please go ahead with this @spiffxp !

commented

+1 from me as well, this would help out in a lot of areas.

commented

+1

commented

I would like to scope out and propose a solution that involves wg-k8s-infra taking on ownership and administration of the kubernetes.io GSuite instance

Since WGs are supposed to eventually wrap up, will transitioning ownership to a permanent group like a SIG be a later responsibility of WG k8s Infra?

commented

Will transitioning ownership to a permanent group like a SIG be a later responsibility of WG k8s Infra?

Yeah, I see this going one of two ways:

  • all responsibilities are sharded out to the appropriate SIG, (e.g. the automation code and running of it is owned by SIG ContribEx (much as they own slack-infra right now))
  • the WG becomes a SIG

I would be happy to transition full ownership of the Google Workspace Groups automation to SIG ContribEx today except for the fact that it lacks the rule-based exclusion that slack-infra has which allows for better delegation to subdir OWNERS. It's sortof why we have a ContribEx TL as one of the root-level approvers for groups changes.

commented

OK I have an account, it's protected by 2FA. Going to need some time to come back to you with a more fully formed proposal, my hope is by the start of v1.23

commented

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

commented

/remove-lifecycle stale
/lifecycle frozen