On Thu, Apr 30, 2020 at 09:00:51PM -0300, Daniel Henrique Barboza wrote:
My initial plan is to get the logic/APIs design from Libvirt, rename
them in a Gopher fashion, re-code it with Go and call it a day :)
That is really not a way I would like to go, as that means we immediately
inherit the design bias of the current libvirt code. The goal is to be
able to replace current libvirt code eventually, but I don't want it to
just be a clone of that code, as I think it misses the opportunity to
try to design something better than what we have done.
As a particular example.. the current placement code has no conceptual
model of machine types present in QEMU. We've just got many "if" tests
that take different codepaths based on heuristics about the machine
type. I would like the new API to have an explicit conceptual model
of each machine type we intend to support. ie it should have full
representation of the default topology of devices that are mandated
by the machine type. Ideally this modelling should be extendable
without having to write code in the placement model. ie we should
be able to load a "i440fx.yaml" file describing the i440fx machine
type and the placement logic "just works". We should not have any
tests like "if (is i440fx)" in the code itself.
The libvirt code shows us the range of features we need to support at
least though.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|