Re: [libvirt] [PATCH v2 6/6] tools: make virt-host-validate check CPU vulnerabilities

On Mon, Sep 30, 2019 at 05:10:10PM +0200, Andrea Bolognani wrote: > On Mon, 2019-09-30 at 15:30 +0100, Daniel P. Berrangé wrote: > > - Having separated data from the code it is obviously possible to > > extend this without introducing any code changes. This is possible > > to use from outside libvirt. For example there are usage scenarios > > which may not be supported by certain versions of QEMU. The QEMU > > package can drop in some facts which will be picked up by the > > virt-host-validate tool. Alternatively going up the stack, an > > app like OpenStack which uses libvirt may wish to restrict what > > they use, or wish to check extra virt host features interesting > > to their app's usage of libvirt. Again their package can now > > drop in extra facts. > > This last point is the only advantage I can see very clearly. I'm > not sure it's worth introducing a specific format for, though. >

> > - New features can be built ontop of the declarative data. At first > > I just set out to replicate the existing tool's output as is. Once > > that was done, it was obvious that we could trivially add a new > > feature allowing us to print the raw informationm about each > > fact that was checked, as an alternative to the human targetted > > message strings. IOW we got a machine readable output format > > essentially for free by virtue of using declarative data. > > This is a benefit of storing the information as facts, which as I > said before I think is a good idea; it doesn't mean we have to > obtain said facts by processing YAML files. Of course you could define everything via a set of structs in the code, but its crazy to do that as you've now hardcoded everything at build time, pointlessly throwing away the key extensibility benefit of having it defined via a data file.

> > - The implementation can be rewritten again at will. If the original > > C code had this split of data vs processing logic, this conversion > > of langauge would have been even more compelling, as none of othe > > declarative data would have needed changing. I'm not expecting > > another rewrite, but this capability was already valuable, between > > the v1 and v2 posting of this patch I changed from XML to YAML for > > the data format. This conversion was entirely automated, because > > it could be algorithmically processed. > > If you had used code instead of a pure data format as the source for > information, then you wouldn't have needed to perform that conversion > in the first place O:-) 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 :|