Hello Eric, On Monday 13 February 2012 18:43:21 Eric Blake wrote: > > 2. Instead of implementing a second variant of offset='variable' it would > > be enough to just add an attribute reset='true' (or > > this_is_not_from_a_buggy_libvirt_and_I_really_need_the_reset='true') to > > dumpxml, when a driver really implements the reset semantics. As long as > > it's missing, libvirt can convert it to reset='false' in the Xen≥3.1 > > case. With an explicit reset='true' libvirt would return an error for > > Xen-HV≥3.1. > > Once we add a new attribute, we can document that domain XML that omits > the attribute will default to hypervisor-specific choices (xen < 3.1 can > default one way, xen >= 3.1 can default another way, and qemu can > default in a particular way as well). If the user provides the > attribute, then they are requesting the specific behavior that they need. v3 implements this as following: adjustment='reset' forced the old behaviour with xen; xen-3.1 will reject those HV-domains. adjustment='$timeDelta' gets directly converted to offset='variable'. > No. We _don't_ want a libvirt version attribute. What we want is a new > attribute that, if present, determines the behavior according to the > user, and if absent, provides sane upgrade semantics when parsing older > XML into newer libvirt. Okay. Thank you for your explanation; makes sense. > You still haven't managed to convince me that we cannot solve this by > adding new attributes. I still find it a little bit strange to add an attribute to force the parser to the old behaviour of utc/localtime, which was perfectly clear. But if it improves compatibility, I'm fine with this solution. Thank you for your feedback so far. BYtE Philipp -- Philipp Hahn Open Source Software Engineer hahn univention de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/
Description: This is a digitally signed message part.