Tunir needs bare metal for some of the things it does but that's not something we really support with our current execution structure.
The "how will things be routed?" question is taken care of elsewhere - this is about taking the current bare metal boxes used for Autocloud and getting them into buildbot such that we can route Tunir tasks to them.
I'll bite. Why should we implement routing of specific tasks to specific bare metal machines (and probably maintain them, yuck!), instead of giving Tunir a disposable minion with nested virt enabled and let it do whatever it wants with it? That's most probably easier to implement (provided that nested virt works correctly, that we need to find out), and it's generic - many other checks will want to have this, not just Tunir.
! In #713#9539, @kparal wrote: I'll bite. Why should we implement routing of specific tasks to specific bare metal machines (and probably maintain them, yuck!), instead of giving Tunir a disposable minion with nested virt enabled and let it do whatever it wants with it? That's most probably easier to implement (provided that nested virt works correctly, that we need to find out), and it's generic - many other checks will want to have this, not just Tunir.
Virtualbox does not work on nested virt. It will only work on bare metal. While we had nest virt for the libvirt section of the tests, that caused way too much kernel error logs to the infra team, that is why we decided to go for full bare metal.
Metadata Update from @tflink: - Issue tagged with: infrastructure
Login to comment on this ticket.