7:58 a.m.
https://bugzilla.redhat.com/show_bug.cgi?id=523639
feature request which makes sense to me, the simple patch attached
seems to be sufficient, one can define and have the description back
in the dump. Doesn't try to keep the location of the tag, it always
get serialized after <uuid>.
The only drawbacks I can think of are:
- others XML formats may require the same, but honnestly it's trivial
- machine generated description (for example if the history log of
a domain gets stored there) could grow a lot and I wonder if we
have a hard limit on the size when transmitting xml descriptions
Oh and I didn't found a good place to test the feature, i.e. no test
seems to parse and reserialize XML it's always about conversions.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
8:49 a.m.
2009/9/30 Daniel Veillard <veillard(a)redhat.com>:
https://bugzilla.redhat.com/show_bug.cgi?id=523639
feature request which makes sense to me, the simple patch attached
seems to be sufficient, one can define and have the description back
in the dump. Doesn't try to keep the location of the tag, it always
get serialized after <uuid>.
The only drawbacks I can think of are:
- others XML formats may require the same, but honnestly it's trivial
- machine generated description (for example if the history log of
a domain gets stored there) could grow a lot and I wonder if we
have a hard limit on the size when transmitting xml descriptions
Such a machine generated description would contradict the intention of
Rubin Simons for this description entry. IMHO this description entry
should be used for user-provided descriptions only. For any other
purpose (like a history log) another entry should be added.
Oh and I didn't found a good place to test the feature, i.e. no
test
seems to parse and reserialize XML it's always about conversions.
Daniel
ACK.
This will be easy to support in the ESX driver, because a virtual
machine has an free-format annotation field where this description can
be stored.
Matthias
9:19 a.m.
On Wed, Sep 30, 2009 at 03:49:05PM +0200, Matthias Bolte wrote:
2009/9/30 Daniel Veillard <veillard(a)redhat.com>:
> https://bugzilla.redhat.com/show_bug.cgi?id=523639
>
> feature request which makes sense to me, the simple patch attached
> seems to be sufficient, one can define and have the description back
> in the dump. Doesn't try to keep the location of the tag, it always
> get serialized after <uuid>.
> The only drawbacks I can think of are:
> - others XML formats may require the same, but honnestly it's trivial
> - machine generated description (for example if the history log of
> a domain gets stored there) could grow a lot and I wonder if we
> have a hard limit on the size when transmitting xml descriptions
Such a machine generated description would contradict the intention of
Rubin Simons for this description entry. IMHO this description entry
yes but between a feature intent and how people (ab)use it, sometimes
one need to be careful :-)
should be used for user-provided descriptions only. For any other
purpose (like a history log) another entry should be added.
well no, a log should be maintained externally IMHO :-)
> Oh and I didn't found a good place to test the feature, i.e.
no test
> seems to parse and reserialize XML it's always about conversions.
>
> Daniel
>
ACK.
This will be easy to support in the ESX driver, because a virtual
machine has an free-format annotation field where this description can
be stored.
Okidoc, pushed, you can extend the ESX conversions then, maybe that
will allow to test the round trip parse and restore too :-)
thanks,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9:22 a.m.
On Wed, Sep 30, 2009 at 03:49:05PM +0200, Matthias Bolte wrote:
2009/9/30 Daniel Veillard <veillard(a)redhat.com>:
> https://bugzilla.redhat.com/show_bug.cgi?id=523639
>
> feature request which makes sense to me, the simple patch attached
> seems to be sufficient, one can define and have the description back
> in the dump. Doesn't try to keep the location of the tag, it always
> get serialized after <uuid>.
> The only drawbacks I can think of are:
> - others XML formats may require the same, but honnestly it's trivial
> - machine generated description (for example if the history log of
> a domain gets stored there) could grow a lot and I wonder if we
> have a hard limit on the size when transmitting xml descriptions
Such a machine generated description would contradict the intention of
Rubin Simons for this description entry. IMHO this description entry
should be used for user-provided descriptions only. For any other
purpose (like a history log) another entry should be added.
I agree that a '<description>' element should be exclusively for
user supplied free-form text, not interpreted by applications.
THe history log is the kind of idea that makes me think we should
group it inside the top level <metadata> element.
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 :|
9:37 a.m.
On Wed, Sep 30, 2009 at 03:22:43PM +0100, Daniel P. Berrange wrote:
On Wed, Sep 30, 2009 at 03:49:05PM +0200, Matthias Bolte wrote:
> 2009/9/30 Daniel Veillard <veillard(a)redhat.com>:
> > https://bugzilla.redhat.com/show_bug.cgi?id=523639
> >
> > feature request which makes sense to me, the simple patch attached
> > seems to be sufficient, one can define and have the description back
> > in the dump. Doesn't try to keep the location of the tag, it always
> > get serialized after <uuid>.
> > The only drawbacks I can think of are:
> > - others XML formats may require the same, but honnestly it's trivial
> > - machine generated description (for example if the history log of
> > a domain gets stored there) could grow a lot and I wonder if we
> > have a hard limit on the size when transmitting xml descriptions
>
> Such a machine generated description would contradict the intention of
> Rubin Simons for this description entry. IMHO this description entry
> should be used for user-provided descriptions only. For any other
> purpose (like a history log) another entry should be added.
I agree that a '<description>' element should be exclusively for
user supplied free-form text, not interpreted by applications.
THe history log is the kind of idea that makes me think we should
group it inside the top level <metadata> element.
Hum, I'm not sure I follow, you would like to create a metadata
container at the top level and put <description> in it ? The problem
is that I don't see what else we could move there.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
10:09 a.m.
On Wed, Sep 30, 2009 at 04:37:46PM +0200, Daniel Veillard wrote:
On Wed, Sep 30, 2009 at 03:22:43PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 30, 2009 at 03:49:05PM +0200, Matthias Bolte wrote:
> > 2009/9/30 Daniel Veillard <veillard(a)redhat.com>:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=523639
> > >
> > > feature request which makes sense to me, the simple patch attached
> > > seems to be sufficient, one can define and have the description back
> > > in the dump. Doesn't try to keep the location of the tag, it always
> > > get serialized after <uuid>.
> > > The only drawbacks I can think of are:
> > > - others XML formats may require the same, but honnestly it's
trivial
> > > - machine generated description (for example if the history log of
> > > a domain gets stored there) could grow a lot and I wonder if we
> > > have a hard limit on the size when transmitting xml descriptions
> >
> > Such a machine generated description would contradict the intention of
> > Rubin Simons for this description entry. IMHO this description entry
> > should be used for user-provided descriptions only. For any other
> > purpose (like a history log) another entry should be added.
>
> I agree that a '<description>' element should be exclusively for
> user supplied free-form text, not interpreted by applications.
> THe history log is the kind of idea that makes me think we should
> group it inside the top level <metadata> element.
Hum, I'm not sure I follow, you would like to create a metadata
container at the top level and put <description> in it ? The problem
is that I don't see what else we could move there.
Yes, like
<domain>
<name>guest</name>
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
<metadata>
<description>blah</description>
</metadata>
....
I didn't mean we should move any other elements - this is just to serve
as a container for future expansion
Other example bits of information we could define metadata elements for
might be the operating system name, the person who created it, the
date on which it was created, the name of the appliance it was based
on, etc, etc.
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 :|
8:45 a.m.
On Wed, Sep 30, 2009 at 04:09:38PM +0100, Daniel P. Berrange wrote:
On Wed, Sep 30, 2009 at 04:37:46PM +0200, Daniel Veillard wrote:
> Hum, I'm not sure I follow, you would like to create a metadata
> container at the top level and put <description> in it ? The problem
> is that I don't see what else we could move there.
Yes, like
<domain>
<name>guest</name>
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
<metadata>
<description>blah</description>
</metadata>
....
I didn't mean we should move any other elements - this is just to serve
as a container for future expansion
Other example bits of information we could define metadata elements for
might be the operating system name, the person who created it, the
date on which it was created, the name of the appliance it was based
on, etc, etc.
Okay, that makes sense and it's better to have the placeholder now
than mess with different formats later. The trivial patch enclosed does
this,
thanks,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
9:21 a.m.
On Wed, Sep 30, 2009 at 02:58:07PM +0200, Daniel Veillard wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=523639
feature request which makes sense to me, the simple patch attached
seems to be sufficient, one can define and have the description back
in the dump. Doesn't try to keep the location of the tag, it always
get serialized after <uuid>.
The only drawbacks I can think of are:
- others XML formats may require the same, but honnestly it's trivial
I wonder if there's any value in putting it inside a <metadata>
element, so if we add more official metadata fields those can be
grouped in the same place. It also helps to make it clear that
it is not going to have a functional effect on the domain like
the rest of the elements do.
If a hypervisor backend only had a single 'description' field in its
native config format, we could even consider the storing the entire
<metadata> element in that one description field allowing encoding
of arbitrary metadata beyond that supported by the HV in question.
- machine generated description (for example if the history log of
a domain gets stored there) could grow a lot and I wonder if we
have a hard limit on the size when transmitting xml descriptions
The remote protocol has a arbitrary 256 KB limit on all data in a
single message:
const REMOTE_MESSAGE_PAYLOAD_MAX = 262120;
We can increase that limit at any time we like without impacting
ABI - its just a limit to avoid denial of service attacks from
stupidly large messages
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 :|
11:47 a.m.
On Wed, 2009-09-30 at 14:58 +0200, Daniel Veillard wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=523639
feature request which makes sense to me, the simple patch attached
seems to be sufficient, one can define and have the description back
in the dump. Doesn't try to keep the location of the tag, it always
get serialized after <uuid>.
The only drawbacks I can think of are:
- others XML formats may require the same, but honnestly it's trivial
- machine generated description (for example if the history log of
a domain gets stored there) could grow a lot and I wonder if we
have a hard limit on the size when transmitting xml descriptions
Oh and I didn't found a good place to test the feature, i.e. no test
seems to parse and reserialize XML it's always about conversions.
FWIW, I think a lot of this kind of info makes sense to include in the
git changelog, rather than just:
523639 Allows a <description> tag for domains
* docs/schemas/domain.rng: allow one <description> tag in the top level
of the <domain> to store user information as text
* src/conf/domain_conf.c src/conf/domain_conf.h: extend the structure
to store this text, grab it at parse time and save it back when
present after <uuid>
You can commit the patch, write the changelog, then send the patch using
git-format-patch/git-send-email and that way the reviewer sees the same
info the will go into the git changelog
Cheers,
Mark.
5530
days inactive
5531
days old
8 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Mark McLoughlin -
Matthias Bolte