[ovirt-devel] [vdsm] Engine XML: metadata and devices from XML

Francesco Romani fromani at redhat.com
Mon Mar 20 14:20:27 UTC 2017


On 03/20/2017 09:05 AM, Francesco Romani wrote:
> On 03/17/2017 11:07 PM, Michal Skrivanek wrote:
>>> On 17 Mar 2017, at 15:57, Francesco Romani <fromani at 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 <fromani at 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
>

Unfortunately we need to have the prefix for all the elements, not just
for the top-level one. Updating.

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



More information about the Devel mailing list