search

kubernetes / org

Meta configuration for Kubernetes Github Org
Apache License 2.0
241 stars 689 forks source link

Establish repo for artifact promotion configurations #2342

Closed justaugustus closed 2 years ago

justaugustus commented 3 years ago

New Repo, Staging Repo, or migrate existing

Migrate existing: https://github.com/justaugustus/artifacts

Requested name for new repository

https://github.com/kubernetes/artifacts

Which Organization should it reside

kubernetes

If not a staging repo, who should have admin access

  artifact-approvers:
    - bartsmykla # WG K8s Infra Lead
    - dims # WG K8s Infra Lead
    - hasheddan # subproject owner / Release Manager / SIG Technical Lead
    - justaugustus # subproject owner / Release Manager / SIG Chair
    - listx # Container image promoter admin
    - saschagrunert # subproject owner / Release Manager / SIG Chair
    - spiffxp # WG K8s Infra Lead
    - thockin # Container image promoter admin

ref: https://github.com/justaugustus/artifacts/blob/ba6bd79ce72ddcca7fb60c89e8e2612945761989/OWNERS_ALIASES#L5-L13

If not a staging repo, who should have write access

  artifact-reviewers:
    - bartsmykla # WG K8s Infra Lead
    - dims # WG K8s Infra Lead
    - hasheddan # subproject owner / Release Manager / SIG Technical Lead
    - justaugustus # subproject owner / Release Manager / SIG Chair
    - listx # Container image promoter admin
    - saschagrunert # subproject owner / Release Manager / SIG Chair
    - spiffxp # WG K8s Infra Lead
    - thockin # Container image promoter admin

ref: https://github.com/justaugustus/artifacts/blob/ba6bd79ce72ddcca7fb60c89e8e2612945761989/OWNERS_ALIASES#L14-L22

If not a staging repo, who should be listed as approvers in OWNERS

Already configured: https://github.com/justaugustus/artifacts/pull/1

If not a staging repo, who should be listed in SECURITY_CONTACTS

Already configured: https://github.com/justaugustus/artifacts/pull/1

What should the repo description be

Already set: Kubernetes artifact promotion configurations

What SIG and subproject does this fall under in sigs.yaml

This is part of the @kubernetes/release-engineering subproject of @kubernetes/sig-release.

Approvals

This is a core repository which will require approval from @kubernetes/sig-architecture-leads.

I'm opening this to start the approvals process and will follow-up with a note to SIG Arch's ML.

Additional context for request

Initially suggested by @thockin in https://kubernetes.slack.com/archives/CCK68P2Q2/p1603987072094400.

tl;dr of that conversation was as we wrap up the "first phase" of the image promotion process (https://github.com/kubernetes/k8s.io/issues/157), we can consider "the keys" transferred when senior Release Managers can manage artifact promotion and handle incidents.

As part of that, we should shift the artifact promotion configurations over to Release Engineering and establish a new repo for that.

For SIG Arch: /assign @dims @johnbelamaric @derekwaynecarr

For GH Administration: /assign @nikhita @mrbobbytables

cc: @kubernetes/sig-release-leads /sig release architecture /area release-eng artifacts /wg k8s-infra

k8s-ci-robot commented 3 years ago

@justaugustus: The label(s) area/release-eng, area/artifacts cannot be applied, because the repository doesn't have them

In response to [this](https://github.com/kubernetes/org/issues/2342): >### New Repo, Staging Repo, or migrate existing >Migrate existing > >### Requested name for new repository > >https://github.com/justaugustus/artifacts > >### Which Organization should it reside > >kubernetes > >### If not a staging repo, who should have admin access > >```yaml > artifact-approvers: > - bartsmykla # WG K8s Infra Lead > - dims # WG K8s Infra Lead > - hasheddan # subproject owner / Release Manager / SIG Technical Lead > - justaugustus # subproject owner / Release Manager / SIG Chair > - listx # Container image promoter admin > - saschagrunert # subproject owner / Release Manager / SIG Chair > - spiffxp # WG K8s Infra Lead > - thockin # Container image promoter admin >``` > >ref: https://github.com/justaugustus/artifacts/blob/ba6bd79ce72ddcca7fb60c89e8e2612945761989/OWNERS_ALIASES#L5-L13 > >### If not a staging repo, who should have write access > >```yaml > artifact-reviewers: > - bartsmykla # WG K8s Infra Lead > - dims # WG K8s Infra Lead > - hasheddan # subproject owner / Release Manager / SIG Technical Lead > - justaugustus # subproject owner / Release Manager / SIG Chair > - listx # Container image promoter admin > - saschagrunert # subproject owner / Release Manager / SIG Chair > - spiffxp # WG K8s Infra Lead > - thockin # Container image promoter admin >``` > >ref: https://github.com/justaugustus/artifacts/blob/ba6bd79ce72ddcca7fb60c89e8e2612945761989/OWNERS_ALIASES#L14-L22 > >### If not a staging repo, who should be listed as approvers in OWNERS > >Already configured: https://github.com/justaugustus/artifacts/pull/1 > >### If not a staging repo, who should be listed in SECURITY_CONTACTS > >Already configured: https://github.com/justaugustus/artifacts/pull/1 > >### What should the repo description be > >Already set: `Kubernetes artifact promotion configurations` > >### What SIG and subproject does this fall under in sigs.yaml > >This is part of the @kubernetes/release-engineering subproject of @kubernetes/sig-release. > >### Approvals > >This is a core repository which will require approval from @kubernetes/sig-architecture-leads. > >I'm opening this to start the approvals process and will follow-up with a note to SIG Arch's ML. > >### Additional context for request > >Initially suggested by @thockin in https://kubernetes.slack.com/archives/CCK68P2Q2/p1603987072094400. > >tl;dr of that conversation was as we wrap up the "first phase" of the image promotion process (https://github.com/kubernetes/k8s.io/issues/157), we can consider "the keys" transferred when senior Release Managers can manage artifact promotion and handle incidents. > >As part of that, we should shift the artifact promotion configurations over to Release Engineering and establish a new repo for that. > >For SIG Arch: >/assign @dims @johnbelamaric @derekwaynecarr > >For GH Administration: >/assign @nikhita @mrbobbytables > >cc: @kubernetes/sig-release-leads >/sig release architecture >/area release-eng artifacts >/wg k8s-infra Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
thockin commented 3 years ago

IMO having a dedicated repo for this is a win, even if just for better notifications

justaugustus commented 3 years ago

even if just for better notifications

My kingdom for more focused notifications!

justaugustus commented 3 years ago

Approval request sent to SIG Arch ML: https://groups.google.com/g/kubernetes-sig-architecture/c/3HsF1zF0aP4

dims commented 3 years ago

+1 in principle, will look deeper early next week

justinsb commented 3 years ago

To confirm my understanding - is the idea that we will move the image promoter manifests that are current in kubernetes/k8s.io into this new repo? (e.g. https://github.com/kubernetes/k8s.io/tree/master/k8s.gcr.io/images ) Or will this be reserved only for "core" artifacts, and "kubernetes-sigs" artifacts will be managed elsewhere?

justaugustus commented 3 years ago

@justinsb -- so the repo would be "core" in the sense that it's in the kubernetes GH org, but it would contain the image/file configs for all staging projects.

Everything under:

spiffxp commented 3 years ago

I agree this would be better for notifications. However, I am concerned the split of artifact project ACL and provisioning in k8s.io may lead to things falling stale. Can you articulate more of the intended cross-repo workflow and validation?

justaugustus commented 3 years ago

I agree this would be better for notifications. However, I am concerned the split of artifact project ACL and provisioning in k8s.io may lead to things falling stale. Can you articulate more of the intended cross-repo workflow and validation?

Hey @spiffxp, sorry for missing your comment a while back. My understanding of the process for creating staging projects as it exists today (having gone through it a few times myself, with custom use cases for RelEng) is:

  1. PR to add a Google Group for IAM
  2. Populate the promotion skeleton for the new project
  3. Update the scripts to generate the GCP project
  4. Have a privileged WG K8s Infra person run the script

While those happen in the same PR today, we could disambiguate concerns...

k/k8s.io (WG K8s Infra)

k/artifacts (RelEng / SIG Release)

Example workflow:

  1. group files an issue and/or PR in k/k8s.io to request a project
  2. WG K8s Infra actuates
  3. group files an issue and/or PR in k/artifacts to create a new artifact promotion directory
  4. SIG Release actuates

You mentioned staleness, which suggests validation, which suggests tooling. However, that doesn't exist today and I don't necessarily think we need to block on it.

So what I'm thinking is:

Once the PR is submitted to k/artifacts to create a new promotion directory, a presubmit checks to see if the IAM group exists (store a listing of groups in a yaml file? we already do this). If the group doesn't exist, the PR doesn't merge (and we can throw a bot warning back to docs to guide the user).

Thoughts?

justaugustus commented 3 years ago

Slack discussion thread: https://kubernetes.slack.com/archives/CJH2GBF7Y/p1612214966104300

BenTheElder commented 3 years ago

Requested name for new repository https://github.com/justaugustus/artifacts

lol? 🙃 (presumably just the "artifacts" bit? or is this a takeover? 😛 )

I think notifications will continue to be bad, FWIW (seeing as everyone involved in artifact management will still be in the one repo, and that's easily the most active thing), and every move like this kills link juice sooo ... 🤷‍♂️

spiffxp commented 3 years ago

/milestone v1.21

spiffxp commented 3 years ago

Thoughts?

One nit on proposed workflow: I would prefer treating service as source of truth for gitops driven things, especially those that are manually actuated. So, k8s.gcr.io jobs should check to see if projects/images actually exist, don't trust presence in a .yaml file.

Workflow otherwise SGTM. Block manifest merge on "is manifest valid", which includes existence of source/dest artifacts and appropriate iam.

You mentioned staleness, which suggests validation, which suggests tooling. However, that doesn't exist today and I don't necessarily think we need to block on it.

I think it's fair to ensure we're not locking ourselves into today's no-tooling state forever. I haven't noticed a proposal or design doc, so wanted some reassurance that this had been thought through. That's been met, though I'd still appreciate a pointer to a doc if I've missed it.

spiffxp commented 3 years ago

/milestone v1.22 I don't think we're going to land this in v1.21

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

fejta-bot commented 3 years ago

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.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

spiffxp commented 3 years ago

/milestone clear

justaugustus commented 3 years ago

/remove-lifecycle rotten ref: https://github.com/kubernetes/community/pull/5928

spiffxp commented 3 years ago

/priority important-longterm

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

markjacksonfishing commented 2 years ago

/remove-lifecycle stale

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

reylejano commented 2 years ago

/remove-lifecycle stale

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

k8s-triage-robot commented 2 years ago

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

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

You can:

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

/lifecycle rotten

k8s-triage-robot commented 2 years ago

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

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

You can:

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

/close

k8s-ci-robot commented 2 years ago

@k8s-triage-robot: Closing this issue.

In response to [this](https://github.com/kubernetes/org/issues/2342#issuecomment-1228717672): >The Kubernetes project currently lacks enough active 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: >- Reopen this issue or PR with `/reopen` >- Mark this issue or PR as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.