On Fri, Oct 19, 2007 at 01:35:25PM +0100, Richard W.M. Jones wrote: > >>>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. It depends on the level of configuration. I don't want the sysadmin to be configuring command line args directly. For any input XML metadata to the libvirt API, we should always run a pre-determined command argv. This is important to ensure that the same storage description results in the same underlying operations no matter what machine it is run on. This ensures that applications have a consistent API, and that people debugging bug reports don't have to worry about local modifications to the API's meaning. The sysadmin can define the configure the storage pools they wish to have available via the APIs we provide directly. Now, if we want the sys-admin to be able to provide specific command line tools, for storage then I'd suggest we add an explicit 'site local' storage pool type. A 'site local' pool type would simple hand all the operations off to sysadmin configured commands. This way, if they use the built in lvm, or file, or iscsi, or block device backends we know exactly what the results are going to be. If they use the 'site local' backend we know to expect the unexpected. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list