Re: [Libvir] Proposal for the storage API (for discussion only)
On Fri, Oct 19, 2007 at 01:35:25PM +0100, Richard W.M. Jones wrote:
>>See previous discussion about capabilities, also a hack:
>>https://www.redhat.com/archives/libvir-list/2007-March/msg00104.html
>
>The use of XML for describing metadata about managed objects is a core
>aspect of libvirt. We can debate use of XML vs structures for hours on
>end, but the fact remains that libvirt uses XML for its metadata APIs.
XML is used in a few places: As a way to describe domains (in & out) and
for capabilities (out). The original capabilities proposal didn't use
XML -- I'm not proud that I folded on that one.
virConnectGetCapabilities returns sprawling XML that differs in ways we
don't really understand between hypervisors. We have avoided defining
real meanings to much of the capabilities XML. This is not a good
example to follow.
If this is going to be decided by some sort of popularity contest
(`libvirt uses XML already so why not use a bit more'), then how about
we look at other comparable C libraries. How many of them return XML
from API calls, that is when they're not returning HTML documents or the
like?
IMHO, consistent style to our APIs is important. As you say we already use
XML for describing domains, virtual networks, and capabilities. Introducing
a different approach just for describing storage just does not make sense
to me at all, thus I want storage to be described using XML in the immediate
implementation.
That said I do recognise that there are some benefits to having APIs that
operate in terms of statically typed structures. I am open to discussing
how we could introduce new APIs equivalent to the existing create & dumpxml
APIs - for *all* objects we represent. I think this should be a effort
that is separate / in parallel with the addition of storage management
APIs so we don't block implementation of the storage.
If we look at the QEMU driver we already have structs to hold the working
representation of a domain and a network. The 'test' driver also has its
own structs. With some appropriate adjustments we could potentially make
the QEMU structs generic enough that we'd be able to expose them via the
public API. This could open up some interesting possibilities for reducing
the amount of code in the internal drivers. Current we have
- XM config -> XML parser
- XML -> XM config parser
- SEXPR -> XML parser
- XML -> SEXPR parser
- qemu struct -> XML formatter
- XML -> qemu struct parser
- test struct -> XML formatter
- XML -> test struct parser
As a first step, we could switch to using the 'qemu' structs inside all the
drivers as the working representations. This would result in a single parser
and single formatter across all drivers. We'd then just need to do a SEXPR
to struct convertor & XM config to struct convertor.
Once the internals were unified, we'd have a higher degree of confidience
that our struct design was sufficiently flexible for all drivers. Though
it would be nice to have one virt backend which wasn't styled on the QEMU
device model - VMWare potentially hsa a quite different set of metadata.
Anyway, if we had the internals all unified on a single struct design, then
we could make the next step & expose virDomainCreateStruct(virDomainStructPtr)
and virDomainStructPtr virDomainGetDescription() as equivalents for the
existing virDomainCreate and virDOmainDumpXML methods - likewise for the
storage, networking and capabilities APIs.
Personally I'd like to do the unification of all the drivers to use the
same structs internally anyway. I think it would result in more straight
forward code & actually make it quicker & easier to write new backends.
The vast majority of the work in backends is doing the XML parser and
formatter. If we have a single intenral struct representation, adding a
UserModeLinux driver could reuse nearly all of the QEMU driver code
as is. All we would end is a new method to build up the ARGV for spawning
the UML kernels.
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 -=|