[libvirt] [PATCH] introducing <source> <name> (for logical storage pools)

[Daniel Berrange]

On Fri, Aug 08, 2008 at 03:17:52PM -0400, David Lively wrote:
>   Daniel B proposed having storage pool discovery return a bunch of XML
> storage <source> elements, rather than full <pool> elements (which
> contain "target-dependent" details like the local pool name and device
> or mount path -- things which don't need to be decided unless/until the
> pool is defined).  
> 
>   I like his suggestion a lot, and I think it addresses the final
> API-definition problem keeping storage pool discovery out of libvirt.
> But ... it doesn't quite work for logical storage pools because those
> are created from the <pool> <name> element (which is the same as the
> volume group name).

Yep, I half-expected that format decision to come back & haunt me :-( 

>   ???This patch introduces a new <source> element <name>, which is
> distinct
> from the pool name.  <name> is used only by the logical storage
> backend, and represents the volume group name.  For convenience and
> back-compatibility, <source> <name> defaults to the pool name if not
> specified when the pool is defined, and <pool> <name> defaults to the
> source name if not specified.  There is no requirement that pool and
> source name be the same, though.
> 
>   While admittedly it seems a little weird, it does allow more
> flexibility (pool name not tied to vol group name), and allows <source>
> to fully specify a logical pool source, as it does for the other pool
> types[*].  Defaulting the source name from the pool name means all
> existing pool XML definitions continue to work.  Defaulting the pool
> name from the source name is simply a matter of convenience (but perhaps
> a step too far?)
> 
>   If this is accepted, logical pool discovery can then return a bunch of
> sources like:
>    <source><name>VolGroup00</name></source>
>    <source><name>VolGroup01</name></source>



> 
>   Please note I'll be on vacation next week (Aug 11-15), so I may not be
> responding until the following week.
> 
> Thanks,
> Dave
> 
> [*] Well ... almost.  Note that directory pools have a similar issue --
> the "source" of the pool is given by the <target> <path> -- there's no
> <source>.  I suppose implementing directory pool discovery (for the sake
> of completeness) means addressing this as well, maybe via some similar
> mechanism ...

We already have a <source><directory>....</directory></source> element
we use for NFS exports. I didn't bother with it for directory pools
because it'd be duplicating info from the target path, but in retrospect
we should use it for directory pools. 

Perhaps we could even use it for the LVM pools instead of adding a new
<name> element - eg,  

   <source><directory>/dev/VolGroup00</directory></source>
   <source><directory>/dev/VolGroup01</directory></source>

I don't feel too strongly about this though - either name or directory
in the source would do the job for LVM pools nicely.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|