Make NPD release more scalable

[wangzhen127]

Currently NPD release can only be done by @wangzhen127 manually due to historical reasons. We should look into making this more scalable, e.g., to make releases for CVEs in time.

[wangzhen127]

CC a few folks who may be interested at helping. @hakman @daveoy @DigitalVeer @AnishShah

[daveoy]

I'd like to put my hand up for elevated responsibilities.

[hakman]

Already did some things in the past on this front, I guess we have to just make the binaries from node-problem-detector-push-images be publishable. For reference this is why we are not using those binaries now #865.
A few other known problems:

• binaries are not uploaded to the GitHub release automatically
• staging images are pushed with the master tag: gcr.io/k8s-staging-npd/node-problem-detector:master

[wangzhen127]

Yeah, the release process is still very manual today. We can probably do the following step by step:

1. Create a "release team". Start releasing NPD with some regular cadence or on demand manually.
2. Look into making the release more automated.
3. Look into Introduce a branching model for vulnerability fixes #1062, potentially addressing this together with step 2 above.

Reading https://github.com/kubernetes/node-problem-detector/blob/master/docs/release_process.md again, I think the release team member just needs the following:

• Access to container image staging registry.
• Write permission to the npd github repo to make new releases.

@hakman @daveoy Given you are interested, do you mind creating a PR similar to kubernetes/k8s.io#1599 for your access to the container image staging registry? You can assign the PR to me.

Regarding repo write access, I am not the repo owner or admin since I don't see Settings tab. Not sure how this is managed. @BenTheElder do you know?

[hakman]

I think it's a good plan.
Repo write access comes with approver privileges. I am not aware on any other way. @ameukam any thoughts?
If we fix the push to staging via the push-images job, there should be no need for manual access to image registry.

[ameukam]

Yeah. the repo admins have write access to the repo. Publishing artifacts to Github shouldn't be an issue.
For images publication to the staging registry, it can be done with a post-submit like it's done here for all the sub-projects: https://github.com/kubernetes/test-infra/tree/master/config/jobs/image-pushing

[wangzhen127]

Is repo admin equivalent to approver in OWNERS file?

In addition to push-image job, is there a make-release job? Even though I manually write the release notes today, the content is using some standard format. It could be auto generated I think.

[BenTheElder]

Repo admin is usually managed via a github team which is then managed in https://github.com/kubernetes/org

Where possible we make things declarative, the teams are in simple YAML files. Connecting the team to repo permissions is done manually once during repo setup by the admins of kubernetes/org

[BenTheElder]

This repo may predate that, you can file an issue with the org repo for support from the github org team that can update repo setting and point you to setting up a github team managed in the YAML there (which sig node could then self-approve updates to)

[wangzhen127]

Thanks for the information! I filed kubernetes/org#5638

[wangzhen127]

@daveoy Looks like you are not a Kubernetes member yet? Not sure if I can add you to kubernetes/org#5640

[daveoy]

Hmmm how can I fix that?

[SergeyKanzhelev]

Hmmm how can I fix that?

https://github.com/kubernetes/community/blob/master/community-membership.md#member