labels: Add wg/ipam group label

[oshoval]

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

[oshoval]

/cc @enp0s3 @maiqueb @qinqon @brianmcarey

can you please take a look ?
requested by Igor

[fabiand]

/hold

[fabiand]

Folks, I'm really wondering what is going on.

How the heck did we end up with a sig-wg-* prefix?
Who defined the semantics?
Can everybody invent sigs?

PR's like this require us to think about how we formalize - to add more prorcesses that nobody wants - the introductoin of sigs - to define ownership in KubeVirt.

Again: SIGs to define ownership of non-overlapping areas within KubeVirt.
A SIG can then decide on itself how to divide it's area among members. One idea is to use wg-*.

[fabiand]

/cc @vladikr fyi - how things start to move if we do not solidify the model aroudn sigs etc.

[oshoval]

Np thanks, it was draft and i raised a question on slack to understand what name to use
Do you mean sig-network-wg-ipam ? or just wg-ipam ?

[fabiand]

Maybe I was a little bit harsh, I see now it's sig/wg-ipam, thus not sig-wg-ipam.

We can also not just define wg-ipam - it must be associated to a SIG. How do we do this?

Once it is solved, then please use wg/ipam instead of sig/wg-ipam.

[fabiand]

It feels like sig/network plus a new label wg/ipam could indicate the right thing:

Owned by sig network, handled by wg ipam.

[oshoval]

hmm, not sure i did correct (pushed change before i read newest comments)
will need to understand better how to do what you suggested
atm changed to sig/network-wg-ipam

[oshoval]

updated the label to wg/ipam
hope i understood you correct (once i do, i will update the owners file in the other PR with all the required changes)
thanks

[enp0s3]

Folks, I'm really wondering what is going on.

How the heck did we end up with a sig-wg-* prefix? Who defined the semantics? Can everybody invent sigs?

PR's like this require us to think about how we formalize - to add more prorcesses that nobody wants - the introductoin of sigs - to define ownership in KubeVirt.

Again: SIGs to define ownership of non-overlapping areas within KubeVirt. A SIG can then decide on itself how to divide it's area among members. One idea is to use wg-*.

@fabiand @vladikr This PR just reflects an attempt to comply with what was discussed on Monday's approvres meeting.
IIUC there was a push back from having individual approvers in specific packages, thus the idea with WG came up.

Now to be more specific, with regards to IPAM PR
The situation is simple - ex sig-network maintainers are willing to maintain IPAM package, while current sig-network maintainers don't.

If the WG procedure is yet defined, can we proceed with having individual approvers in pkg/libipam/OWNERS?

[fabiand]

In this comment, please sync to sig-network charter in community repo. In sig network charter, please add wg-ipam.

[oshoval]

updated this PR (hope i understood correct)
and created kubevirt/community#300

[fabiand]

@enp0s3 understood.

My main concern was abut the usage of the string sig-wg-iapm (which was a misunderstanding on my side).

As stated above:
sigs own code.
wg are internal structures to delegate who is handling it.

thus we
a) need to make the connection between wg ipam and sig network
b) sig network remains to own the code/area, wg ipam will handle that specific piece and has trust by sig network to even approve it.

To me the current PR is thus much better, as it's introducing wg/ipam.

I'd expect the owners file to then include buth

approvers
- wg/ipam
 - sig/network

unless the file is anyway in a sig-network owned directory, then the sig-network can be omitted because it's getting inherited.

[fabiand]

@oshoval thanks for your openess! and the quick turnaround

The PR including the IMPORTANT links (for user context) to community and label PRs are good.

/unhold

/lgtm

[oshoval]

Thanks Fabian for the help here

@brianmcarey @enp0s3 can you please take a look ?

[dhiller]

All, sorry for not being able to bring the PR around the initial wgs for arch to life soon enough: kubevirt/community#298

/approve

Thanks @oshoval

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dhiller

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:

• OWNERS [dhiller]

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

[kubevirt-bot]

@oshoval: Updated the label-config configmap in namespace kubevirt-prow at cluster default using the following files:

• key labels.yaml using file github/ci/prow-deploy/kustom/base/configs/current/labels/labels.yaml

In response to this:

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.