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

On 03/18/2017 01:14 PM, Nir Soffer wrote: > > > On Fri, Mar 17, 2017 at 4:58 PM Francesco Romani <fromani(a)redhat.com > <mailto:fromani@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(a)redhat.com <mailto:fromani@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... > > > > 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> > > > Why do we need this nesting? We use libvirt metadata for elements; so each direct child of metadata is a separate metadata grop: ovirt-tune:qos is one ovirt-vm:vm is one 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) > > > <ovirt-instance:graphics> > > > What is ovirt-instance? Gone, merged with ovirt-vm ovirt-vm will hold both per-vm metadata and per-device metadata. > > > <specParams> > <fileTransferEnable>true</fileTransferEnable> > <copyPasteEnable>true</copyPasteEnable> > <displayIp>192.168.1.51</displayIp> > <keyMap>en-us</keyMap> > <spiceSslCipherSuite>DEFAULT</spiceSslCipherSuite> > > <spiceSecureChannels>smain,sinputs,scursor,splayback,srecord,sdisplay,ssmartcard,susbredir</spiceSecureChannels> > <displayNetwork>ovirtmgmt</displayNetwork> > </specParams> > </ovirt-instance:graphics> > <ovirt-instance:disk> > <specParams> > > > Why do we need this nesting? *Here* we had this nesting because the example took vm.conf and brutally translated to XML. Is a worst case scenario. Why is it relevant? There it was initial discussion about how to deal with complex device; to minimize changes, we could marshal the existing vm.conf into the device metadata, then unmarshal on Vdsm side and just use it to rebuild the devices with the very same code we have today (yes, this means sneaking/embedding vm.conf into the XML) Should we go that way, it could look like the above. Let's talk in general now. There are three main use cases requiring nesting: 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 <metadata> <ovirt-vm:vm> <foo>1</foo> <bar>2</bar> </ovirt-vm:vm> </metadata> this is simple and nice and I think is not bothering anyone (hopefully :)) 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 <metadata> <ovirt-vm:vm> <foo>1</foo> <bar>2</bar> <devices> <device> <fast>true</fast> <cheap>false</cheap> </device> </devices> </ovirt-vm:vm> </metadata> 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" Would that look good?

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 the process-wide metadata gateway.

> > > <path /> > </specParams> > </ovirt-instance:disk> > <ovirt-instance:disk> > <specParams /> > > <domainID>c578566d-bc61-420c-8f1e-8dfa0a18efd5</domainID> > > > We are using sd_id, img_id and vol_id now for these in new storage code. Noted > > > > <volumeID>5c4eeed4-f2a7-490a-ab57-a0d6f3a711cc</volumeID> > <poolID>5890a292-0390-01d2-01ed-00000000029a</poolID> > > <imageID>66441539-f7ac-4946-8a25-75e422f939d4</imageID> > > > We need more info about disks, like diskType, shared, discard, etc. > > Can you show a complete vm xml with metadata? Will post as soon as possible. -- Francesco Romani Red Hat Engineering Virtualization R & D IRC: fromani

_______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel