Kind provider

[aerosouund]

What this PR does / why we need it:

Adds capabilities to run kind clusters in the gocli

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:

This PR is opened as a draft because its based on the Opts PR which may receive changes and has not been merged yet. it also doesn't include code that integrates this capability with cluster-up. as this is yet left for discussion

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

Adds capabilities to run kind clusters in the gocli

[kubevirt-bot]

Hi @aerosouund. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

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.

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign rmohr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

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

[aerosouund]

cc: @dhiller @brianmcarey @xpivarc @acardace

[EdDev]

An impressive work has been done here.

The SR-IOV lane is effected by this change.
Unfortunately, the sig-network which have been maintaining in practice this area has no resources to invest into kubevirtci at this time.

Therefore, I would suggest to avoid modifying the kind and SR-IOV portions so we can continue supporting it.

Said that, if someone else will take over and provide the support and maintain the new changes, I''ll be be good with it.

[aerosouund]

@EdDev
Thanks a lot and that's understandable due to the size of the change.

I would like to provide support for this code myself and do have plans for long term maintenance of it under supervision of one of the kubevirt CI approvers

[oshoval]

This will also create dependencies between vm based providers and kind providers (via gocli)
eliminating benefits of provision manager, and the fact there will be dependency between the providers
makes it impossible to advance with one while the other have problems as happened sometimes
(and provision manager allowed solving it, hence saving developers time + saving CI time)

[aerosouund]

@oshoval
I see your concerns, however I personally don't see them overlapping in terms of dependencies
while yes, they both will be a part of the gocli, the only thing they share in terms of the dependencies is the k8s package and the ssh package, which were designed to be agnostic to what type of cluster you are using.

makes it impossible to advance with one while the other have problems as happened sometimes

very reasonable concern, can you give me an example of when this might arise ?

eliminating benefits of provision manager

I haven't looked at the provision manager a lot as it didn't seem to be affected by what I am doing, but I'd appreciate you highlighting how it relates to what you are describing. what does it add and how does a change like that cancel its benefits ?

[aerosouund]

@oshoval

In general I think this code will still need to go through some reviews before a serious discussion is had about whether or no to actually use it
If you have the time I would highly appreciate if you check it out and see its inner workings and if you see ways of how to make it better

[oshoval]

@oshoval

In general I think this code will still need to go through some reviews before a serious discussion is had about whether or no to actually use it If you have the time I would highly appreciate if you check it out and see its inner workings and if you see ways of how to make it better

Sorry, i wouldn't able to, i am committed to some urgent tasks

[oshoval]

@oshoval I see your concerns, however I personally don't see them overlapping in terms of dependencies while yes, they both will be a part of the gocli, the only thing they share in terms of the dependencies is the k8s package and the ssh package, which were designed to be agnostic to what type of cluster you are using.

makes it impossible to advance with one while the other have problems as happened sometimes

very reasonable concern, can you give me an example of when this might arise ?

We had it not once, when one vm based version was broken, and it affected all the other vm based versions / kind
because they either merged or not together
provision manager improved this by saying what files affect which provider, allowing PRs to test just the required changes, and also not provision where not needed.
As even the provision itself consume resources, bump packages and can introduce bugs.

eliminating benefits of provision manager

I haven't looked at the provision manager a lot as it didn't seem to be affected by what I am doing, but I'd appreciate you highlighting how it relates to what you are describing. what does it add and how does a change like that cancel its benefits ?

once gocli affect kind providers, and becomes a bigger library that includes most of the core code,
provision manager wont able to declare that gocli doesnt affect anymore kind based providers.

[aerosouund]

once gocli affect kind providers, and becomes a bigger library that includes most of the core code,
provision manager wont able to declare that gocli doesn't affect anymore kind based providers.

After checking out the provision-manager command i have a take on this
to rephrase what you are saying, I see that the purpose of pman is to determine if a change to the repo requires the VM providers to be built again
and it's currently configured to rebuild all providers on any change to the gocli. so by making kind in the gocli we introduce the problem of having to rebuild VMs even if we are changing kind logic

understandable, and this problem can be tackled by having more granular rules

The logic is not entirely shared. As i say there's already a limited amount of shared code between the two in the gocli. so the pman rules file can be changed to exclude directories that are known to be pure kind logic
the code structure also can be altered to have an even higher degree of separation and make management structure much more clear

While this sounds like more complexity on the surface but the benefit accrued from having more navigable, testable and extensible kind code is worth considering

I also see this to be lesser complexity than the current state of kind. in terms of it being a series of source somescript.sh calls

[kubevirt-bot]

PR needs rebase.

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.