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

[Martin Kletzander]

On Mon, Sep 30, 2019 at 04:30:18PM +0100, Daniel P. Berrangé wrote:
>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.
>>

Yes, this one I haven't thought of and it makes sense.  It also makes way more
sense for it not to be a part of libvirt, but rather a separate project as if
the support for loading other files from elsewhere is added, there is no need
for this to be a part of libvirt any more.  Which would immediately overrule
(almost) all issues I have seen with this.

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

Except when you are using extensive conditionals or building the fact from
multiple pieces information using, for example, boolean expressions.  At that
point you are creating a programming language on top of markup language.

>> >  - 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 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20191001/17a6a896/attachment-0001.sig>