Prototype a new CLI bmhvm

[Rozzii]

This is an advanced task. Take it only if you are already comfortable with golang, libvirt and containers.

We currently use bash scripts to set up sushy-tools and create VMs to be used as BareMetalHosts. This works, but it is not ideal. It is inflexible, hard to reuse between CI and development, and even harder to reuse from other repositories like CAPM3.

The goal of this task is to prototype a golang CLI (call it for example bmhvm) that can do the same thing these scripts do today. It should also be usable as a go library that can be imported in CAPM3 for example. The tool should be able to set up sushy-tools on top of either podman or docker. It should be able to create a libvirt network and create VMs in this network.

You will need to work with the libvirt golang library: https://pkg.go.dev/libvirt.org/go/libvirt

Here are some suggestions for how it should work.

• bmhvm init should create a libvirt network and run sushy-tools
• bmhvm create vm should create a VM
• bmhvm generate bmh should generate a BareMetalHost manifest for a VM

Note that you can reuse some parts here.

[metal3-io-bot]

This issue is currently awaiting triage.
If Metal3.io contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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/test-infra repository.

[dtantsur]

@Rozzii would it help if we put that in sushy-tools instead? I'm a bit worried about potential duplication: we already have many places where the same logic is used.

[Rozzii]

@dtantsur yeah I think we can go into that direction, and as you have mentioned let's first specify the exact scope of this and figure out the configuration format.
/triage accepted

[metal3-io-bot]

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

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

/lifecycle stale

[Rozzii]

/remove-lifecycle stale

[metal3-io-bot]

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

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

/lifecycle stale

[Rozzii]

/lifecycle frozen

[mquhuy]

/assign

[Rozzii]

/remove-lifecycle frozen
We had a discussion with @mquhuy and realized that he has done much of he hard work when in terms of implementing go based libvirt tooling here https://github.com/metal3-io/baremetal-operator/tree/main/test/createVM.

After some discussion we have decided that this VM tooling would be used across the project and the best place for it would be in project-infra. CAPM3, IPAM and BMO would use it as a GO package while dev-env would use it as a cli tool.

[lentzi90]

After some discussion we have decided that this VM tooling would be used across the project and the best place for it would be in project-infra. CAPM3, IPAM and BMO would use it as a GO package while dev-env would use it as a cli tool.

I'm not sure project-infra is the best place. Yes it will be used across projects, but I do think it belongs with BMO. We should publish the CLI as a build artifact binary that dev-env can use. In CAPM3 I think we should use it as a go module directly, and this is the reason I want it in BMO. CAPM3 depends on BMO already and this is a natural dependency. Depending on project-infra as a module feels wrong to me.

[tuminoid]

I'm not sure project-infra is the best place. Yes it will be used across projects, but I do think it belongs with BMO. We should publish the CLI as a build artifact binary that dev-env can use. In CAPM3 I think we should use it as a go module directly, and this is the reason I want it in BMO. CAPM3 depends on BMO already and this is a natural dependency. Depending on project-infra as a module feels wrong to me.

I agree that CAPM3 or BMO should not depend on go package from project-infra. I'm not exactly loving the idea of having VM tools in BMO either, but it is more closely related to BMO than anything else.