[libvirt] [PATCH v2 0/8] Add ability to store notes with domains

[Daniel P. Berrange]

On Mon, Jan 23, 2012 at 09:46:57AM -0700, Eric Blake wrote:
> On 01/23/2012 09:23 AM, Daniel P. Berrange wrote:
> >> Changing <title> or <description> of a transient domain is a
> >> nice-to-have, but not the end of the world.  Changing <metadata> of a
> >> transient domain is a must-have, so we need at least one new API.
> >> Setting is important, while getting is only a shortcut (we can make the
> >> user call virDomainGetXMLDesc, and do an XPath query), but symmetry is
> >> nice.  Meanwhile, libvirt shouldn't care about the contents of
> >> <metadata>, other than that it is a well-formed XML string.  We do _not_
> >> need virTypedParams, but can stick with just an enum for which piece of
> >> metadata to be modifying.  We can get by with just one API for all three
> >> elements, as well as leaving the door open for any future metadata.  So
> > 
> > For the <metadata> element we want more tha njust a well-formed XML
> > string. The intention is that every top level element inside
> > <metadata> *must* declare its own private XML namespace. The
> > default namespace is to be reserved for any libvirt official metadata
> > elements we might introduce in the future.
> 
> Do we want to start out with <description> or even <title> as our first
> libvirt-official metadata (that is, in the spirit of backcompat, output:
> 
> <domain ...>
>   <description>desc</description>
>   <metadata>
>     <description>desc</description>
>   </metadata>
> </domain>

Nah, I feel that's just overkill - it is harmless having description
and title outside the block IMHO.

> > While fine for title/description, I don't think this really works
> > for <metadata>.  When setting the metadata we'd want to specify
> > an XML namespace key and URI, and when getting the metadata we'd
> > really want to specify a namespace URI
> 
> Ah, so you're thinking of getting at an individual sub-element within
> <metadata>, where I was thinking of grabbing the entire <metadata>
> element and making the user sift through the sub-elements to the ones
> they want.  Your proposal does indeed make a bit more sense, in saving
> the user some effort for filtering to just the metadata elements they
> care about, and when setting things, they can set just the ones they
> care about while leaving all other existing metadata elements untouched
> (instead of having to do a read-modify-write cycle).  Your proposal also
> makes it easier to force the user to specify a namespace for each
> element that goes into metadata.  But it also makes it sound like we are
> imposing one additional constraint on <metadata> - each subelement must
> be a distinct namespace, so you cannot have multiple top-level metadata
> elements from the same namespace.

That is correct - basically the top level element would be a container
inside which all the app's metadata would live, so I'd expect apps todo

   <metadata>
     <virtman:guest xmlns:virtman="http://virt-manager.org/guets/1.0">
         <ostype>linux</ostype>
         <osvariant>fedora16</osvariant>
     </virtman:guest>
   </metadata>

And *not*

   <metadata>
     <virtman:ostype xmlns:virtman="http://virt-manager.org/guets/1.0">linux</virtman:ostype>
     <virtman:osvariant xmlns:virtman="http://virt-manager.org/guets/1.0">fedora16</virtman:osvariant>
   </metadata>


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|