<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 03/18/2017 01:14 PM, Nir Soffer wrote:<br>
<blockquote
cite="mid:CAMRbyyu0i7vE6Qz7Xr2vz=3BmBVH6CtATavuGhL06==mO_K2bw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Mar 17, 2017 at 4:58 PM Francesco
Romani <<a moz-do-not-send="true"
href="mailto:fromani@redhat.com">fromani@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">On
03/16/2017 08:03 PM, Francesco Romani wrote:<br
class="gmail_msg">
> On 03/16/2017 01:26 PM, Francesco Romani wrote:<br
class="gmail_msg">
>> On 03/16/2017 11:47 AM, Michal Skrivanek wrote:<br
class="gmail_msg">
>>>> On 16 Mar 2017, at 09:45, Francesco Romani
<<a moz-do-not-send="true"
href="mailto:fromani@redhat.com" class="gmail_msg"
target="_blank">fromani@redhat.com</a>> wrote:<br
class="gmail_msg">
>>>><br class="gmail_msg">
>>>> We talked about sending storage device
purely on metadata, letting Vdsm<br class="gmail_msg">
>>>> rebuild them and getting the XML like
today.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> In the other direction, Vdsm will pass
through the XML (perhaps only<br class="gmail_msg">
>>>> parts of it, e.g. the devices subtree) like
before.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> This way we can minimize the changes we are
uncertain of, and more<br class="gmail_msg">
>>>> importantly, we can minimize the risky
changes.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> The following is a realistic example of
how the XML could look like if<br class="gmail_msg">
>>>> we send all but the storage devices. It is
built using my pyxmlpickle<br class="gmail_msg">
>>>> module (see [3] below).<br
class="gmail_msg">
>>> That’s quite verbose. How much work would it
need to actually minimize it and turn it into something more
simple.<br class="gmail_msg">
>>> Most such stuff should go away and I believe it
would be beneficial to make it difficult to use to
discourage using metadata as a generic junkyard<br
class="gmail_msg">
>> It is verbose because it is generic - indeed
perhaps too generic.<br class="gmail_msg">
>> I can try something else based on a concept from
Martin Polednik. Will<br class="gmail_msg">
>> follow up soon.<br class="gmail_msg">
> Early preview:<br class="gmail_msg">
> <a moz-do-not-send="true"
href="https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-compact"
rel="noreferrer" class="gmail_msg" target="_blank">https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-compact</a><br
class="gmail_msg">
><br class="gmail_msg">
> still plenty of TODOs, I expect to be reviewable
material worst case<br class="gmail_msg">
> monday morning.<br class="gmail_msg">
<br class="gmail_msg">
This is how typical XML could look like:<br
class="gmail_msg">
<br class="gmail_msg">
<metadata><br class="gmail_msg">
<ovirt-tune:qos /><br class="gmail_msg">
<ovirt-vm:vm /><br class="gmail_msg">
<devices><br class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>Why do we need this nesting?</div>
</div>
</div>
</blockquote>
<br>
We use libvirt metadata for elements; so each direct child of
metadata is a separate metadata grop:<br>
<br>
ovirt-tune:qos is one<br>
ovirt-vm:vm is one<br>
<br>
and so forth. I don't want to mess up with the existing elements.
So we could be backward compatible at XML level (read: 4.1 XML works
without changes to 4.2)<br>
<br>
<br>
<blockquote
cite="mid:CAMRbyyu0i7vE6Qz7Xr2vz=3BmBVH6CtATavuGhL06==mO_K2bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<ovirt-instance:graphics><br
class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>What is ovirt-instance?</div>
</div>
</div>
</blockquote>
<br>
Gone, merged with ovirt-vm<br>
<br>
ovirt-vm will hold both per-vm metadata and per-device metadata.<br>
<br>
<blockquote
cite="mid:CAMRbyyu0i7vE6Qz7Xr2vz=3BmBVH6CtATavuGhL06==mO_K2bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<specParams><br class="gmail_msg">
<fileTransferEnable>true</fileTransferEnable><br
class="gmail_msg">
<copyPasteEnable>true</copyPasteEnable><br
class="gmail_msg">
<displayIp>192.168.1.51</displayIp><br
class="gmail_msg">
<keyMap>en-us</keyMap><br
class="gmail_msg">
<spiceSslCipherSuite>DEFAULT</spiceSslCipherSuite><br
class="gmail_msg">
<br class="gmail_msg">
<spiceSecureChannels>smain,sinputs,scursor,splayback,srecord,sdisplay,ssmartcard,susbredir</spiceSecureChannels><br
class="gmail_msg">
<displayNetwork>ovirtmgmt</displayNetwork><br
class="gmail_msg">
</specParams><br class="gmail_msg">
</ovirt-instance:graphics><br
class="gmail_msg">
<ovirt-instance:disk><br class="gmail_msg">
<specParams><br class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>Why do we need this nesting?</div>
</div>
</div>
</blockquote>
<br>
*Here* we had this nesting because the example took vm.conf and
brutally translated to XML. Is a worst case scenario.<br>
<br>
Why is it relevant? There it was initial discussion about how to
deal with complex device; to minimize changes, we could<br>
marshal the existing vm.conf into the device metadata, then
unmarshal on Vdsm side and just use it to rebuild the devices<br>
with the very same code we have today (yes, this means
sneaking/embedding vm.conf into the XML)<br>
<br>
Should we go that way, it could look like the above.<br>
<br>
<br>
Let's talk in general now. There are three main use cases requiring
nesting:<br>
<br>
1. per-vm metadta. Attach key/value pairs. We need one level of
nesting to avoid to mess up with other data. So it could look like<br>
<br>
<metadata><br>
<ovirt-vm:vm><br>
<foo>1</foo><br>
<bar>2</bar><br>
</ovirt-vm:vm><br>
</metadata><br>
<br>
this is simple and nice and I think is not bothering anyone
(hopefully :))<br>
<br>
2. per-device metadata: it has to fit into vm section, and we could
possibly have more than one device with metadata, so the simplest
format is something like<br>
<br>
<metadata><br>
<ovirt-vm:vm><br>
<foo>1</foo><br>
<bar>2</bar><br>
<devices><br>
<device><br>
<fast>true</fast><br>
<cheap>false</cheap><br>
</device><br>
</devices><br>
</ovirt-vm:vm><br>
</metadata><br>
<br>
This is the minimal nesting level we need. We could gather the
per-device metadata in a dict and feed device with it, like with a
new "meta" argument to device constructor, much like "custom" and
"specParams"<br>
<br>
Would that look good?<br>
<br>
<br>
3. QoS. we need to support the current layout for obvious backward
compatibility questions. We could postpone this and use existing
code for some more time, but ultimately this should handled by
metadata module, just because it is supposed to be<br>
the process-wide metadata gateway.<br>
<br>
<blockquote
cite="mid:CAMRbyyu0i7vE6Qz7Xr2vz=3BmBVH6CtATavuGhL06==mO_K2bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAMRbyyu0i7vE6Qz7Xr2vz=3BmBVH6CtATavuGhL06==mO_K2bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<path /><br class="gmail_msg">
</specParams><br class="gmail_msg">
</ovirt-instance:disk><br
class="gmail_msg">
<ovirt-instance:disk><br class="gmail_msg">
<specParams /><br class="gmail_msg">
<domainID>c578566d-bc61-420c-8f1e-8dfa0a18efd5</domainID><br
class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>We are using sd_id, img_id and vol_id now for these in
new storage code.</div>
</div>
</div>
</blockquote>
<br>
Noted<br>
<br>
<blockquote
cite="mid:CAMRbyyu0i7vE6Qz7Xr2vz=3BmBVH6CtATavuGhL06==mO_K2bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<volumeID>5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</volumeID><br
class="gmail_msg">
<poolID>5890a292-0390-01d2-01ed-00000000029a</poolID><br
class="gmail_msg">
<imageID>66441539-f7ac-4946-8a25-75e422f939d4</imageID><br
class="gmail_msg">
</blockquote>
<div><br>
</div>
<div>We need more info about disks, like diskType, shared,
discard, etc.</div>
<div><br>
</div>
<div>Can you show a complete vm xml with metadata?</div>
</div>
</div>
</blockquote>
<br>
Will post as soon as possible.<br>
<br>
<pre class="moz-signature" cols="72">--
Francesco Romani
Red Hat Engineering Virtualization R & D
IRC: fromani</pre>
</body>
</html>