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/