From mkolesni at redhat.com Thu Mar 22 05:04:05 2012 Content-Type: multipart/mixed; boundary="===============2498740720974912546==" MIME-Version: 1.0 From: Mike Kolesnik To: devel at ovirt.org Subject: [Engine-devel] Forward comp[atibility of OVF Date: Thu, 22 Mar 2012 05:04:04 -0400 Message-ID: In-Reply-To: ed8c42d9-86e7-4766-986b-2c6c619d8a5b@zmail14.collab.prod.int.phx2.redhat.com --===============2498740720974912546== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --=3D_bc9b6b95-2d7c-4155-b37b-029c2446b231 Content-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 7bit Hi, = I wanted to know if we want to support forward compatibility of OVF format,= which is used for export/import of VMs/VM Templates. = For example, = I create a VM in a 3.1 system, export it to an export Domain. = Should I be able to import this VM on a 3.0 system? = Obviously, backwards compatibility (from older version to newer) is desired= and is kept , but do we really need forward compatibility also? = The reason I'm asking is some changes that need to be done in current OVF f= ormat to support new features. These new changes will be backwards-compatib= le with old OVF formats, but is it desirable for them to be forward compati= ble? = Regards, = Mike = --=3D_bc9b6b95-2d7c-4155-b37b-029c2446b231 Content-Type: text/html; charset=3Dutf-8 Content-Transfer-Encoding: quoted-printable <=3D div style=3D3D'font-family: Times New Roman; font-size: 12pt; color: #00000= 0'=3D >Hi,

I wanted to know if we want to support forward compatibility of= =3D OVF format, which is used for export/import of VMs/VM Templates.

Fo= =3D r example,
I create a VM in a 3.1 system, export it to an export Domain= =3D .
Should I be able to import this VM on a 3.0 system?

Obviously, = =3D backwards compatibility (from older version to newer) is desired and is kep= =3D t, but do we really need forward compatibility also?

The reason I'm = =3D asking is some changes that need to be done in current OVF format to suppor= =3D t new features. These new changes will be backwards-compatible with old OVF= =3D formats, but is it desirable for them to be forward compatible?

Regards,
Mike
<= /div=3D >
--=3D_bc9b6b95-2d7c-4155-b37b-029c2446b231-- --===============2498740720974912546== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS09X2JjOWI2Yjk1LTJkN2MtNDE1NS1iMzdiLTAyOWMyNDQ2YjIzMQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoK SGksIAoKSSB3YW50ZWQgdG8ga25vdyBpZiB3ZSB3YW50IHRvIHN1cHBvcnQgZm9yd2FyZCBjb21w YXRpYmlsaXR5IG9mIE9WRiBmb3JtYXQsIHdoaWNoIGlzIHVzZWQgZm9yIGV4cG9ydC9pbXBvcnQg b2YgVk1zL1ZNIFRlbXBsYXRlcy4gCgpGb3IgZXhhbXBsZSwgCkkgY3JlYXRlIGEgVk0gaW4gYSAz LjEgc3lzdGVtLCBleHBvcnQgaXQgdG8gYW4gZXhwb3J0IERvbWFpbi4gClNob3VsZCBJIGJlIGFi bGUgdG8gaW1wb3J0IHRoaXMgVk0gb24gYSAzLjAgc3lzdGVtPyAKCk9idmlvdXNseSwgYmFja3dh cmRzIGNvbXBhdGliaWxpdHkgKGZyb20gb2xkZXIgdmVyc2lvbiB0byBuZXdlcikgaXMgZGVzaXJl ZCBhbmQgaXMga2VwdCAsIGJ1dCBkbyB3ZSByZWFsbHkgbmVlZCBmb3J3YXJkIGNvbXBhdGliaWxp dHkgYWxzbz8gCgpUaGUgcmVhc29uIEknbSBhc2tpbmcgaXMgc29tZSBjaGFuZ2VzIHRoYXQgbmVl ZCB0byBiZSBkb25lIGluIGN1cnJlbnQgT1ZGIGZvcm1hdCB0byBzdXBwb3J0IG5ldyBmZWF0dXJl cy4gVGhlc2UgbmV3IGNoYW5nZXMgd2lsbCBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIG9s ZCBPVkYgZm9ybWF0cywgYnV0IGlzIGl0IGRlc2lyYWJsZSBmb3IgdGhlbSB0byBiZSBmb3J3YXJk IGNvbXBhdGlibGU/IAoKClJlZ2FyZHMsIApNaWtlIAoKCi0tPV9iYzliNmI5NS0yZDdjLTQxNTUt YjM3Yi0wMjljMjQ0NmIyMzEKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgK Q29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKPGh0bWw+PGhlYWQ+ PHN0eWxlIHR5cGU9M0QndGV4dC9jc3MnPnAgeyBtYXJnaW46IDA7IH08L3N0eWxlPjwvaGVhZD48 Ym9keT48PQpkaXYgc3R5bGU9M0QnZm9udC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbjsgZm9udC1z aXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCc9Cj5IaSw8YnI+PGJyPkkgd2FudGVkIHRvIGtub3cg aWYgd2Ugd2FudCB0byBzdXBwb3J0IGZvcndhcmQgY29tcGF0aWJpbGl0eSBvZj0KIE9WRiBmb3Jt YXQsIHdoaWNoIGlzIHVzZWQgZm9yIGV4cG9ydC9pbXBvcnQgb2YgVk1zL1ZNIFRlbXBsYXRlcy48 YnI+PGJyPkZvPQpyIGV4YW1wbGUsIDxicj5JIGNyZWF0ZSBhIFZNIGluIGEgMy4xIHN5c3RlbSwg ZXhwb3J0IGl0IHRvIGFuIGV4cG9ydCBEb21haW49Ci48YnI+U2hvdWxkIEkgYmUgYWJsZSB0byBp bXBvcnQgdGhpcyBWTSBvbiBhIDMuMCBzeXN0ZW0/PGJyPjxicj5PYnZpb3VzbHksID0KYmFja3dh cmRzIGNvbXBhdGliaWxpdHkgKGZyb20gb2xkZXIgdmVyc2lvbiB0byBuZXdlcikgaXMgZGVzaXJl ZCBhbmQgaXMga2VwPQp0LCBidXQgZG8gd2UgcmVhbGx5IG5lZWQgZm9yd2FyZCBjb21wYXRpYmls aXR5IGFsc28/PGJyPjxicj5UaGUgcmVhc29uIEknbSA9CmFza2luZyBpcyBzb21lIGNoYW5nZXMg dGhhdCBuZWVkIHRvIGJlIGRvbmUgaW4gY3VycmVudCBPVkYgZm9ybWF0IHRvIHN1cHBvcj0KdCBu ZXcgZmVhdHVyZXMuIFRoZXNlIG5ldyBjaGFuZ2VzIHdpbGwgYmUgYmFja3dhcmRzLWNvbXBhdGli bGUgd2l0aCBvbGQgT1ZGPQogZm9ybWF0cywgYnV0IGlzIGl0IGRlc2lyYWJsZSBmb3IgdGhlbSB0 byBiZSBmb3J3YXJkIGNvbXBhdGlibGU/PGJyPjxicj48ZGk9CnY+PHNwYW4gbmFtZT0zRCJ4Ij48 L3NwYW4+UmVnYXJkcyw8YnI+TWlrZTxzcGFuIG5hbWU9M0QieCI+PC9zcGFuPjxicj48L2Rpdj0K Pjxicj48L2Rpdj48L2JvZHk+PC9odG1sPgotLT1fYmM5YjZiOTUtMmQ3Yy00MTU1LWIzN2ItMDI5 YzI0NDZiMjMxLS0K --===============2498740720974912546==-- From lpeer at redhat.com Thu Mar 22 05:37:08 2012 Content-Type: multipart/mixed; boundary="===============5315340303080746917==" MIME-Version: 1.0 From: Livnat Peer To: devel at ovirt.org Subject: Re: [Engine-devel] Forward comp[atibility of OVF Date: Thu, 22 Mar 2012 11:37:05 +0200 Message-ID: <4F6AF2C1.9080903@redhat.com> In-Reply-To: d7c57832-0cb5-48eb-b673-f6dd64a800a5@zmail14.collab.prod.int.phx2.redhat.com --===============5315340303080746917== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 22/03/12 11:04, Mike Kolesnik wrote: > Hi, > = > I wanted to know if we want to support forward compatibility of OVF > format, which is used for export/import of VMs/VM Templates. > = > For example, > I create a VM in a 3.1 system, export it to an export Domain. > Should I be able to import this VM on a 3.0 system? > = I think we should support only backwards compatibility no need for forward compatibility. The question is should we block importing such a VM (that it's version is not something the engine identifies) I think we should block it otherwise the engine will import the VM which can fail sometimes with errors like NullPointerException which will end-up being filed as a BZ. > Obviously, backwards compatibility (from older version to newer) is > desired and is kept, but do we really need forward compatibility also? > = > The reason I'm asking is some changes that need to be done in current > OVF format to support new features. These new changes will be > backwards-compatible with old OVF formats, but is it desirable for them > to be forward compatible? > = > Regards, > Mike > = > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --===============5315340303080746917==-- From mkolesni at redhat.com Thu Mar 22 05:38:56 2012 Content-Type: multipart/mixed; boundary="===============8918403643634329112==" MIME-Version: 1.0 From: Mike Kolesnik To: devel at ovirt.org Subject: Re: [Engine-devel] Forward comp[atibility of OVF Date: Thu, 22 Mar 2012 05:38:55 -0400 Message-ID: <749e2dbf-732a-46e4-aff5-93ad234917b5@zmail14.collab.prod.int.phx2.redhat.com> In-Reply-To: 4F6AF2C1.9080903@redhat.com --===============8918403643634329112== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > On 22/03/12 11:04, Mike Kolesnik wrote: > > Hi, > > = > > I wanted to know if we want to support forward compatibility of OVF > > format, which is used for export/import of VMs/VM Templates. > > = > > For example, > > I create a VM in a 3.1 system, export it to an export Domain. > > Should I be able to import this VM on a 3.0 system? > > = > = > I think we should support only backwards compatibility no need for > forward compatibility. > The question is should we block importing such a VM (that it's > version > is not something the engine identifies) I think we should block it > otherwise the engine will import the VM which can fail sometimes with > errors like NullPointerException which will end-up being filed as a > BZ. I agree that this should be blocked, however to do so for older versions wi= ll require extra work that i don't know if we need or not.. > = > = > > Obviously, backwards compatibility (from older version to newer) is > > desired and is kept, but do we really need forward compatibility > > also? > > = > > The reason I'm asking is some changes that need to be done in > > current > > OVF format to support new features. These new changes will be > > backwards-compatible with old OVF formats, but is it desirable for > > them > > to be forward compatible? > > = > > Regards, > > Mike > > = > > = > > = > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > = >=20 --===============8918403643634329112==--