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 :|
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
