ipam: integrate w/ k8s multi-network defacto standard persistent IPs

[maiqueb]

What this PR does / why we need it: This PR adds a design document outlining how to integrate the persistent IPs feature of the kubernetes multi-networking de-facto standard into KubeVirt.

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:

NONE

[maiqueb]

/assign @AlonaKaplan

[EdDev]

/cc

/sig network

[maiqueb]

Thank you for posting this interesting proposal.

In addition to the review comments, I was thinking about trying to propose an alternative that decouples Kubevirt from the IPClaim in both directions.

I'm not sure if it is best to discuss it in a thread here, but it can be a good initial start.

It is in the spirit of IPClaim having its own controller, but not being dependent on Kubevirt directly. I will try to write something early next week or update back if I fail.

I honestly don't see how that is possible without traversing the pod's owner reference tree upward until its root using unstructured ... which is ... very ugly. That was the only "generic" way I can think of tying the IPAMClaim to an arbitrary resource type that would own it.

I prefer to go for something simple, straight-forward, and easy to reason about for the one use case we have in front of us instead of going for the gold and try to envision workload types we have no requirements for (and don't even know what they might be).

But be my guest - try to come up with something.

[AlonaKaplan]

Thanks!

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: AlonaKaplan

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](https://github.com/kubevirt/community/blob/main/OWNERS)~~ [AlonaKaplan] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[oshoval]

Thanks !

/lgtm