On 03/17/2017 11:07 PM, Michal Skrivanek wrote:
>> On 17 Mar 2017, at 15:57, Francesco Romani <from...@redhat.com> wrote:
>> On 03/16/2017 08:03 PM, Francesco Romani wrote:
>>> On 03/16/2017 01:26 PM, Francesco Romani wrote:
>>>> On 03/16/2017 11:47 AM, Michal Skrivanek wrote:
>>>>>> On 16 Mar 2017, at 09:45, Francesco Romani <from...@redhat.com> wrote:
>>>>>> We talked about sending storage device purely on metadata, letting Vdsm
>>>>>> rebuild them and getting the XML like today.
>>>>>> In the other direction, Vdsm will pass through the XML (perhaps only
>>>>>> parts of it, e.g. the devices subtree) like before.
>>>>>> This way we can minimize the changes we are uncertain of, and more
>>>>>> importantly, we can minimize the risky changes.
>>>>>> The following is  a realistic example of how the XML could look like if
>>>>>> we send all but the storage devices. It is built using my pyxmlpickle
>>>>>> module (see [3] below).
>>>>> That’s quite verbose. How much work would it need to actually minimize it 
>>>>> and turn it into something more simple.
>>>>> 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
>>>> It is verbose because it is generic - indeed perhaps too generic.
>>>> I can try something else based on a concept from Martin Polednik. Will
>>>> follow up soon.
>>> Early preview:
>>> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:virt-metadata-compact
>>> still plenty of TODOs, I expect to be reviewable material worst case
>>> monday morning.
>> This is how typical XML could look like:
>>    <metadata>
>>        <ovirt-tune:qos />
>>        <ovirt-vm:vm />
>>        <devices>
>>            <ovirt-instance:graphics>
> not under the <ovirt-vm:vm>?
> any reason?

No reason, I'll move under it


Francesco Romani
Red Hat Engineering Virtualization R & D
IRC: fromani

Devel mailing list

Reply via email to