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

[S.Sakamoto]

> > 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...)

Shigeki Sakamoto.