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 :|
