[Libvir] Proposal for the storage API (for discussion only)
fj0588di at aa.jp.fujitsu.com
Fri Oct 19 12:39:07 UTC 2007
> > 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).
(Sorry if irrelevant...)
Because "The XML should be mentioned minimum management information",
I think that it is better to be only frontdev, backdev, type and a kind of the device as now.
Information except it should be examined with these as materials anytime by storage API.
( May not matter,
When I'm thinking about "Bugzilla Bug 329091: [5.2]The disk which the OS is in...",
I thought that "storage API" was such a thing...)
More information about the libvir-list