Open Rozzii opened 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.
@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.
@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
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
/remove-lifecycle stale
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-toolsbmhvm create vm
should create a VMbmhvm generate bmh
should generate a BareMetalHost manifest for a VMNote that you can reuse some parts here.