Re: [ovirt-devel] discussion: URI format for libvirt metadata
The URL that we will go with is "http://ovirt.org/vm/tune".
The address is self explainable, it will contain vm tunable parameters and refer to a web
page explaining the parameters.
10x.
> ----- Forwarded Message -----
> > From: "Dan Kenigsberg" <danken(a)redhat.com>
> > To: "Kobi Ianko" <kobi(a)redhat.com>
> > Cc: devel(a)ovirt.org
> > Sent: Wednesday, May 28, 2014 2:16:43 AM
> > Subject: Re: [ovirt-devel] discussion: URI format for libvirt metadata
> >
> > On Tue, May 27, 2014 at 01:10:22PM -0400, Kobi Ianko wrote:
> > > Hi All,
> > > In the upcoming changes we have decided to use the Metadata section of
> > > libvirt to store temporary data. (see
> > > http://libvirt.org/html/libvirt-libvirt.html#virDomainGetMetadata)
> > > For that the libvirt api forces us to specify a valid URI.
> > >
> > > I have suggested using the following pattern:
> > > "http://ovirt.org/param/param_name"
> > >
> > > pro: it's very simple and straightforward.
> > > con: it leads to nowhere and I don't think we should create a web
> > > reference
> > > for each param.
> > >
> > > I would like to hear other suggestions from you all
> >
> > According to
> > http://libvirt.org/html/libvirt-libvirt.html#virDomainSetMetadata
> > """
> > ... VIR_DOMAIN_METADATA_ELEMENT @metadata must be well-formed XML
> > belonging
> > to namespace defined by @uri with local name @key.
> > """
> > so there is no doubt that we must have a properly-defined namespace on
> > the
> > URI.
> >
> > Beyond that, lacking a wiki page explaining the the key, means that a
> > reviewer knows nothing about what is this param, what are its valid
> > values, or how oVirt is using it.
> >
> > Nothing makes sure that no one else in oVirt decides to use the
> > same param for something else.
> >
> > It is important to explain that the params that you suggest are going to
> > be used for communication beween Vdsm and MoM, and that this param is a
> > vm-specific entity. http://ovirt.org/param/name seems like a parameter
> > of ovirt at large, not the CPU of a particular VM.
> >
> > Regards,
> > Dan.
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>