On Fri, Mar 17, 2017 at 4:58 PM 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> > Why do we need this nesting? > <ovirt-instance:graphics> > What is ovirt-instance? ovirt-tune and ovirt-vm make sense, I can guess what you mean, I don't have any idea what is ovirt-instance. > <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? > <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. > <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? > </ovirt-instance:disk> > </devices> > </metadata> > > still working on this > > -- > Francesco Romani > Red Hat Engineering Virtualization R & D > IRC: fromani > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel