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. > >This is just pushing the parsing code out of libvirt and into an external >application. I am saying that libvirt should deal with it directly, since >this is the core job of the driver APIs. libvirt should call 'vgs' directly >and parse its output directly. Adding extra layers in the stack which >transform vgs output into some further intermediate form is not going to >make this easy to debug. I think this is fair enough. The important part is to make sure that the sysadmin can configure it, and it doesn't make much difference whether we use scriptlets or just have configuration options.