Re: [Libvir] Proposal for the storage API (for discussion only)

> This is just one reason why I don't like the idea of simply running shell > scripts in the back end. This will result in a unreliable, hard-to debug > system. It may be a short term win on implementation speed, but it will be > a PITA for long term maintainence. One thing you will immediately get is > people writing scripts which add all kinda of custom crap to the XML > destroying the benefit of libvirt which is the standardization. For any I don't understand this. Scripts can be written which add custom fields to the XML, but since libvirt will just ignore those fields I don't see any issue. > given storage backend, we know what operations we need to be able to > perform & so we have a finite set of commands we need to run with known > predictable arguments. We just don't need the 'flexibility' of running > arbitrary shell scripts & XML filters in the backend end. We do because we need to be able to take the output of 'vgs', 'sfdisk', 'iscsiadm', etc., the output of each being essentially the same information (a list of volume groups plus the size and free space of each), and present that information in the same format back to libvirt. In this case a common format makes perfect sense. It need not be XML, it might be CSV, but in this case XML's extensibility makes sense, along with the fact that libvirt already parses XML. (Note for people snoozing through this email, we're talking about two different uses of XML).