metal3-io / metal3-dev-env

Metal³ Development Environment
Apache License 2.0
111 stars 118 forks source link

Prototype a new CLI bmhvm #1370

Open Rozzii opened 5 months ago

Rozzii commented 5 months ago

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.

Note that you can reuse some parts here.

metal3-io-bot commented 5 months ago

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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
dtantsur commented 5 months ago

@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 commented 5 months ago

@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 commented 2 months ago

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 commented 2 months ago

/remove-lifecycle stale