From leonardo.bianconi at eldorado.org.br Fri Aug 30 15:51:33 2013 Content-Type: multipart/mixed; boundary="===============4671422450400899332==" MIME-Version: 1.0 From: Leonardo Bianconi To: devel at ovirt.org Subject: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Fri, 30 Aug 2013 19:51:28 +0000 Message-ID: <50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br> --===============4671422450400899332== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --_000_50EB20226B72D6419356FC320AB62B8719173370SERV070corpeldo_ Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone! During the development of PPC64 support in the engine, we faced some UX iss= =3D ues regarding the default Cluster (that Cluster with empty processor name). Currently, oVirt engine allows the default Cluster to contain empty process= =3D or name, and the administrator can add VMs and/or Templates to it. The proc= =3D essor name can be assigned later, editing the cluster or assigning a valid = =3D host to it. During the implementation of PPC64 support on the engine, the field "archit= =3D ecture" was added to Clusters, VMs and Templates entities. So we have the following questions regarding how the UI should behave: - Shall we keep allowing the administrator to assign VMs and Templates to t= =3D he Cluster with no processor name or assigned architecture ? -> If we have an "yes" for the question above: -- We will have to assign the architecture to the Cluster base= =3D d on the OS of the first assigned VM, and the processor name could be defi= =3D ned the same way as currently ... editing the Cluster or assigning a compat= =3D ible Host to it. -- The VM creation popup will have to be able = =3D to indicate the architecture of each OS ... some OSes have the same name, a= =3D nd it may get ambiguous since the Cluster architecture is still undefined a= =3D t that point (before the first VM get already created). Thanks! Regards. Leonardo Bianconi --_000_50EB20226B72D6419356FC320AB62B8719173370SERV070corpeldo_ Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone!<=3D /p>

 

During the development of P= PC64=3D support in the engine, we faced some UX issues regarding the default Clust= =3D er (that Cluster with empty processor name).

 

Currently, oVirt engine all= ows =3D the default Cluster to contain empty processor name, and the administrator = =3D can add VMs and/or Templates to it. The processor name can be assigned late= =3D r, editing the cluster or assigning a valid host to it.

 

During the implementation o= f PP=3D C64 support on the engine, the field “architecture“ was added t= =3D o Clusters, VMs and Templates entities.

 

So we have the following qu= esti=3D ons regarding how the UI should behave:

 

- Shall we keep allowing th= e ad=3D ministrator to assign VMs and Templates to the Cluster with no processor na= =3D me or assigned architecture ?

    &nb= sp;&=3D nbsp;       -> If we have an “yes= =3D 221; for the question above:

    &nb= sp;&=3D nbsp;       -- We will have to assign the arc= =3D hitecture to the Cluster based on the OS of the first assigned VM, and = =3D ; the processor name could be defined the same way as currently … edi= =3D ting the Cluster or assigning a compatible Host to it.

    &nb= sp;&=3D nbsp;           &nbs= =3D p;           -- The VM cr= =3D eation popup will have to be able to indicate the architecture of each OS &= =3D #8230; some OSes have the same name, and it may get ambiguous since the Clu= =3D ster architecture is still undefined at that point (before the first VM get already created).= =3D

 

Thanks!

Regards.

Leonardo Bianconi

--_000_50EB20226B72D6419356FC320AB62B8719173370SERV070corpeldo_-- --===============4671422450400899332== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS1fMDAwXzUwRUIyMDIyNkI3MkQ2NDE5MzU2RkMzMjBBQjYyQjg3MTkxNzMzNzBTRVJWMDcwY29y cGVsZG9fCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiCkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUKCkhpIGV2ZXJ5b25lIQoKRHVy aW5nIHRoZSBkZXZlbG9wbWVudCBvZiBQUEM2NCBzdXBwb3J0IGluIHRoZSBlbmdpbmUsIHdlIGZh Y2VkIHNvbWUgVVggaXNzPQp1ZXMgcmVnYXJkaW5nIHRoZSBkZWZhdWx0IENsdXN0ZXIgKHRoYXQg Q2x1c3RlciB3aXRoIGVtcHR5IHByb2Nlc3NvciBuYW1lKS4KCkN1cnJlbnRseSwgb1ZpcnQgZW5n aW5lIGFsbG93cyB0aGUgZGVmYXVsdCBDbHVzdGVyIHRvIGNvbnRhaW4gZW1wdHkgcHJvY2Vzcz0K b3IgbmFtZSwgYW5kIHRoZSBhZG1pbmlzdHJhdG9yIGNhbiBhZGQgVk1zIGFuZC9vciBUZW1wbGF0 ZXMgdG8gaXQuIFRoZSBwcm9jPQplc3NvciBuYW1lIGNhbiBiZSBhc3NpZ25lZCBsYXRlciwgZWRp dGluZyB0aGUgY2x1c3RlciBvciBhc3NpZ25pbmcgYSB2YWxpZCA9Cmhvc3QgdG8gaXQuCgpEdXJp bmcgdGhlIGltcGxlbWVudGF0aW9uIG9mIFBQQzY0IHN1cHBvcnQgb24gdGhlIGVuZ2luZSwgdGhl IGZpZWxkICJhcmNoaXQ9CmVjdHVyZSIgd2FzIGFkZGVkIHRvIENsdXN0ZXJzLCBWTXMgYW5kIFRl bXBsYXRlcyBlbnRpdGllcy4KClNvIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVn YXJkaW5nIGhvdyB0aGUgVUkgc2hvdWxkIGJlaGF2ZToKCi0gU2hhbGwgd2Uga2VlcCBhbGxvd2lu ZyB0aGUgYWRtaW5pc3RyYXRvciB0byBhc3NpZ24gVk1zIGFuZCBUZW1wbGF0ZXMgdG8gdD0KaGUg Q2x1c3RlciB3aXRoIG5vIHByb2Nlc3NvciBuYW1lIG9yIGFzc2lnbmVkIGFyY2hpdGVjdHVyZSA/ CiAgICAgICAgICAgICAtPiBJZiB3ZSBoYXZlIGFuICJ5ZXMiIGZvciB0aGUgcXVlc3Rpb24gYWJv dmU6CiAgICAgICAgICAgICAtLSBXZSB3aWxsIGhhdmUgdG8gYXNzaWduIHRoZSBhcmNoaXRlY3R1 cmUgdG8gdGhlIENsdXN0ZXIgYmFzZT0KZCBvbiB0aGUgT1Mgb2YgdGhlIGZpcnN0IGFzc2lnbmVk IFZNLCBhbmQgIHRoZSBwcm9jZXNzb3IgbmFtZSBjb3VsZCBiZSBkZWZpPQpuZWQgdGhlIHNhbWUg d2F5IGFzIGN1cnJlbnRseSAuLi4gZWRpdGluZyB0aGUgQ2x1c3RlciBvciBhc3NpZ25pbmcgYSBj b21wYXQ9CmlibGUgSG9zdCB0byBpdC4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBU aGUgVk0gY3JlYXRpb24gcG9wdXAgd2lsbCBoYXZlIHRvIGJlIGFibGUgPQp0byBpbmRpY2F0ZSB0 aGUgYXJjaGl0ZWN0dXJlIG9mIGVhY2ggT1MgLi4uIHNvbWUgT1NlcyBoYXZlIHRoZSBzYW1lIG5h bWUsIGE9Cm5kIGl0IG1heSBnZXQgYW1iaWd1b3VzIHNpbmNlIHRoZSBDbHVzdGVyIGFyY2hpdGVj dHVyZSBpcyBzdGlsbCB1bmRlZmluZWQgYT0KdCB0aGF0IHBvaW50IChiZWZvcmUgdGhlIGZpcnN0 IFZNIGdldCBhbHJlYWR5IGNyZWF0ZWQpLgoKVGhhbmtzIQpSZWdhcmRzLgpMZW9uYXJkbyBCaWFu Y29uaQoKLS1fMDAwXzUwRUIyMDIyNkI3MkQ2NDE5MzU2RkMzMjBBQjYyQjg3MTkxNzMzNzBTRVJW MDcwY29ycGVsZG9fCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PSJ1cy1hc2NpaSIK Q29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKPGh0bWwgeG1sbnM6 dj0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0zRCJ1cm46c2NoZW1h cy1taWNyPQpvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0zRCJ1cm46c2NoZW1hcy1t aWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiA9CnhtbG5zOm09M0QiaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0zRCJodHRwOj0KLy93d3cudzMu b3JnL1RSL1JFQy1odG1sNDAiPgo8aGVhZD4KPG1ldGEgaHR0cC1lcXVpdj0zRCJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9M0QidGV4dC9odG1sOyBjaGFyc2V0PTNEdXMtYXNjaWkiPQo+CjxtZXRhIG5h bWU9M0QiR2VuZXJhdG9yIiBjb250ZW50PTNEIk1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBt ZWRpdW0pIj4KPHN0eWxlPjwhLS0KLyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNlCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEu MHB0OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluawoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsKCWNvbG9yOmJsdWU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJ Y29sb3I6cHVycGxlOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxTdHls ZTE3Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Cgljb2xvcjp3aW5kb3d0ZXh0O30KLk1zb0NocERlZmF1bHQKCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0OwoJbWFyZ2luOjcwLjg1cHQgMy4wY20gNzAuODVwdCAzLjBj bTt9CmRpdi5Xb3JkU2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9M0QiZWRpdCIgc3Bp ZG1heD0zRCIxMDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9M0QiZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PTNEImVkaXQi IGRhdGE9M0QiMSIgLz4KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPgo8L2hlYWQ+ Cjxib2R5IGxhbmc9M0QiUFQtQlIiIGxpbms9M0QiYmx1ZSIgdmxpbms9M0QicHVycGxlIj4KPGRp diBjbGFzcz0zRCJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9M0QiRU4tVVMiPkhpIGV2ZXJ5b25lITxvOnA+PC9vOnA+PC9zcGFuPjw9Ci9wPgo8cCBjbGFz cz0zRCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBsYW5nPTNEIkVOLVVTIj5EdXJp bmcgdGhlIGRldmVsb3BtZW50IG9mIFBQQzY0PQogc3VwcG9ydCBpbiB0aGUgZW5naW5lLCB3ZSBm YWNlZCBzb21lIFVYIGlzc3VlcyByZWdhcmRpbmcgdGhlIGRlZmF1bHQgQ2x1c3Q9CmVyICh0aGF0 IENsdXN0ZXIgd2l0aCBlbXB0eSBwcm9jZXNzb3IgbmFtZSkuPG86cD48L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBsYW5nPTNEIkVO LVVTIj5DdXJyZW50bHksIG9WaXJ0IGVuZ2luZSBhbGxvd3MgPQp0aGUgZGVmYXVsdCBDbHVzdGVy IHRvIGNvbnRhaW4gZW1wdHkgcHJvY2Vzc29yIG5hbWUsIGFuZCB0aGUgYWRtaW5pc3RyYXRvciA9 CmNhbiBhZGQgVk1zIGFuZC9vciBUZW1wbGF0ZXMgdG8gaXQuIFRoZSBwcm9jZXNzb3IgbmFtZSBj YW4gYmUgYXNzaWduZWQgbGF0ZT0KciwgZWRpdGluZyB0aGUgY2x1c3RlciBvciBhc3NpZ25pbmcK IGEgdmFsaWQgaG9zdCB0byBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPTNEIk1z b05vcm1hbCI+PHNwYW4gbGFuZz0zRCJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPkR1cmluZyB0aGUg aW1wbGVtZW50YXRpb24gb2YgUFA9CkM2NCBzdXBwb3J0IG9uIHRoZSBlbmdpbmUsIHRoZSBmaWVs ZCAmIzgyMjA7YXJjaGl0ZWN0dXJlJiM4MjIwOyB3YXMgYWRkZWQgdD0KbyBDbHVzdGVycywgVk1z IGFuZCBUZW1wbGF0ZXMgZW50aXRpZXMuPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0z RCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4KPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBsYW5nPTNEIkVOLVVTIj5TbyB3ZSBo YXZlIHRoZSBmb2xsb3dpbmcgcXVlc3RpPQpvbnMgcmVnYXJkaW5nIGhvdyB0aGUgVUkgc2hvdWxk IGJlaGF2ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PHNw YW4gbGFuZz0zRCJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0z RCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPi0gU2hhbGwgd2Uga2VlcCBhbGxvd2lu ZyB0aGUgYWQ9Cm1pbmlzdHJhdG9yIHRvIGFzc2lnbiBWTXMgYW5kIFRlbXBsYXRlcyB0byB0aGUg Q2x1c3RlciB3aXRoIG5vIHByb2Nlc3NvciBuYT0KbWUgb3IgYXNzaWduZWQgYXJjaGl0ZWN0dXJl ID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1hbCI+PHNwYW4gbGFu Zz0zRCJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jj0KbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsgSWYgd2UgaGF2ZSBhbiAmIzgyMjA7 eWVzJiM4PQoyMjE7IGZvciB0aGUgcXVlc3Rpb24gYWJvdmU6PG86cD48L286cD48L3NwYW4+PC9w Pgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9M0QiRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyY9Cm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIFdlIHdpbGwgaGF2ZSB0byBhc3NpZ24gdGhlIGFyYz0KaGl0ZWN0dXJlIHRvIHRo ZSBDbHVzdGVyIGJhc2VkIG9uIHRoZSBPUyBvZiB0aGUgZmlyc3QgYXNzaWduZWQgVk0sIGFuZCZu YnNwPQo7IHRoZSBwcm9jZXNzb3IgbmFtZSBjb3VsZCBiZSBkZWZpbmVkIHRoZSBzYW1lIHdheSBh cyBjdXJyZW50bHkgJiM4MjMwOyBlZGk9CnRpbmcgdGhlIENsdXN0ZXIgb3IgYXNzaWduaW5nIGEK IGNvbXBhdGlibGUgSG9zdCB0byBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPTNE Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0zRCJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jj0KbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzPQpwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBUaGUgVk0gY3I9CmVhdGlvbiBw b3B1cCB3aWxsIGhhdmUgdG8gYmUgYWJsZSB0byBpbmRpY2F0ZSB0aGUgYXJjaGl0ZWN0dXJlIG9m IGVhY2ggT1MgJj0KIzgyMzA7IHNvbWUgT1NlcyBoYXZlIHRoZSBzYW1lIG5hbWUsIGFuZCBpdCBt YXkgZ2V0IGFtYmlndW91cyBzaW5jZSB0aGUgQ2x1PQpzdGVyIGFyY2hpdGVjdHVyZSBpcyBzdGls bCB1bmRlZmluZWQKIGF0IHRoYXQgcG9pbnQgKGJlZm9yZSB0aGUgZmlyc3QgVk0gZ2V0IGFscmVh ZHkgY3JlYXRlZCkuPG86cD48L286cD48L3NwYW4+PQo8L3A+CjxwIGNsYXNzPTNEIk1zb05vcm1h bCI+PHNwYW4gbGFuZz0zRCJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBj bGFzcz0zRCJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9M0QiTXNv Tm9ybWFsIj5SZWdhcmRzLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPkxl b25hcmRvIEJpYW5jb25pPG86cD48L286cD48L3A+CjwvZGl2Pgo8L2JvZHk+CjwvaHRtbD4KCi0t XzAwMF81MEVCMjAyMjZCNzJENjQxOTM1NkZDMzIwQUI2MkI4NzE5MTczMzcwU0VSVjA3MGNvcnBl bGRvXy0tCg== --===============4671422450400899332==-- From rgolan at redhat.com Sun Sep 1 04:07:15 2013 Content-Type: multipart/mixed; boundary="===============3927011372483483895==" MIME-Version: 1.0 From: Roy Golan To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Sun, 01 Sep 2013 11:07:19 +0300 Message-ID: <5222F5B7.5060603@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br --===============3927011372483483895== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------060308090303000405080600 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: > > Hi everyone! > > During the development of PPC64 support in the engine, we faced some = > UX issues regarding the default Cluster (that Cluster with empty = > processor name). > > Currently, oVirt engine allows the default Cluster to contain empty = > processor name, and the administrator can add VMs and/or Templates to = > it. The processor name can be assigned later, editing the cluster or = > assigning a valid host to it. > > During the implementation of PPC64 support on the engine, the field = > "architecture" was added to Clusters, VMs and Templates entities. > > So we have the following questions regarding how the UI should behave: > > - Shall we keep allowing the administrator to assign VMs and Templates = > to the Cluster with no processor name or assigned architecture ? > > -> If we have an "yes" for the question above: > > -- We will have to assign the architecture to the Cluster = > based on the OS of the first assigned VM, and the processor name = > could be defined the same way as currently ... editing the Cluster or = > assigning a compatible Host to it. > > -- The VM creation popup will have to be able to indicate the = > architecture of each OS ... some OSes have the same name, and it may = > get ambiguous since the Cluster architecture is still undefined at = > that point (before the first VM get already created). > > Thanks! > > Regards. > > Leonardo Bianconi > To add VMs you anyway need a running host in the cluster which means the = cpu name and the architecture would be the host's. So we can keep the cluster attributes - "cpu name" and "arch" consistent = and allow them to be empty on creation. > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --------------060308090303000405080600 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit
On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:

Hi everyone!=

 

During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with empty processor name).

 

Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.

 

During the implementation of PPC64 support on the engine, the field “architecture“ was added to Clusters, VMs and Templ= ates entities.

 

So we have the following questions regarding how the UI should behave:=

 

- Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned architecture ?

    = ;         -> If we have an “yes” for the question above:

    = ;         -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name could be defined the same way as currently … editing the Cluster or assigning a compatible Host to it.

    = ;            &n= bsp;            -- The VM creation popup will have to be able to indicate the architecture of each OS … some OSes have the same nam= e, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).

 

Thanks!

Regards.

Leonardo Bianconi


To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation. 


_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel<=
/a>

--------------060308090303000405080600-- --===============3927011372483483895== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNjAzMDgwOTAzMDMwMDA0MDUwODA2MDAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKT24gMDgvMzAvMjAxMyAxMDo1MSBQTSwgTGVvbmFyZG8gQmlhbmNvbmkgd3JvdGU6Cj4K PiBIaSBldmVyeW9uZSEKPgo+IER1cmluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgUFBDNjQgc3VwcG9y dCBpbiB0aGUgZW5naW5lLCB3ZSBmYWNlZCBzb21lIAo+IFVYIGlzc3VlcyByZWdhcmRpbmcgdGhl IGRlZmF1bHQgQ2x1c3RlciAodGhhdCBDbHVzdGVyIHdpdGggZW1wdHkgCj4gcHJvY2Vzc29yIG5h bWUpLgo+Cj4gQ3VycmVudGx5LCBvVmlydCBlbmdpbmUgYWxsb3dzIHRoZSBkZWZhdWx0IENsdXN0 ZXIgdG8gY29udGFpbiBlbXB0eSAKPiBwcm9jZXNzb3IgbmFtZSwgYW5kIHRoZSBhZG1pbmlzdHJh dG9yIGNhbiBhZGQgVk1zIGFuZC9vciBUZW1wbGF0ZXMgdG8gCj4gaXQuIFRoZSBwcm9jZXNzb3Ig bmFtZSBjYW4gYmUgYXNzaWduZWQgbGF0ZXIsIGVkaXRpbmcgdGhlIGNsdXN0ZXIgb3IgCj4gYXNz aWduaW5nIGEgdmFsaWQgaG9zdCB0byBpdC4KPgo+IER1cmluZyB0aGUgaW1wbGVtZW50YXRpb24g b2YgUFBDNjQgc3VwcG9ydCBvbiB0aGUgZW5naW5lLCB0aGUgZmllbGQgCj4gImFyY2hpdGVjdHVy ZSIgd2FzIGFkZGVkIHRvIENsdXN0ZXJzLCBWTXMgYW5kIFRlbXBsYXRlcyBlbnRpdGllcy4KPgo+ IFNvIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgcmVnYXJkaW5nIGhvdyB0aGUgVUkg c2hvdWxkIGJlaGF2ZToKPgo+IC0gU2hhbGwgd2Uga2VlcCBhbGxvd2luZyB0aGUgYWRtaW5pc3Ry YXRvciB0byBhc3NpZ24gVk1zIGFuZCBUZW1wbGF0ZXMgCj4gdG8gdGhlIENsdXN0ZXIgd2l0aCBu byBwcm9jZXNzb3IgbmFtZSBvciBhc3NpZ25lZCBhcmNoaXRlY3R1cmUgPwo+Cj4gICAgICAgICAg ICAgIC0+IElmIHdlIGhhdmUgYW4gInllcyIgZm9yIHRoZSBxdWVzdGlvbiBhYm92ZToKPgo+ICAg ICAgICAgICAgICAtLSBXZSB3aWxsIGhhdmUgdG8gYXNzaWduIHRoZSBhcmNoaXRlY3R1cmUgdG8g dGhlIENsdXN0ZXIgCj4gYmFzZWQgb24gdGhlIE9TIG9mIHRoZSBmaXJzdCBhc3NpZ25lZCBWTSwg YW5kICB0aGUgcHJvY2Vzc29yIG5hbWUgCj4gY291bGQgYmUgZGVmaW5lZCB0aGUgc2FtZSB3YXkg YXMgY3VycmVudGx5IC4uLiBlZGl0aW5nIHRoZSBDbHVzdGVyIG9yIAo+IGFzc2lnbmluZyBhIGNv bXBhdGlibGUgSG9zdCB0byBpdC4KPgo+IC0tIFRoZSBWTSBjcmVhdGlvbiBwb3B1cCB3aWxsIGhh dmUgdG8gYmUgYWJsZSB0byBpbmRpY2F0ZSB0aGUgCj4gYXJjaGl0ZWN0dXJlIG9mIGVhY2ggT1Mg Li4uIHNvbWUgT1NlcyBoYXZlIHRoZSBzYW1lIG5hbWUsIGFuZCBpdCBtYXkgCj4gZ2V0IGFtYmln dW91cyBzaW5jZSB0aGUgQ2x1c3RlciBhcmNoaXRlY3R1cmUgaXMgc3RpbGwgdW5kZWZpbmVkIGF0 IAo+IHRoYXQgcG9pbnQgKGJlZm9yZSB0aGUgZmlyc3QgVk0gZ2V0IGFscmVhZHkgY3JlYXRlZCku Cj4KPiBUaGFua3MhCj4KPiBSZWdhcmRzLgo+Cj4gTGVvbmFyZG8gQmlhbmNvbmkKPgoKVG8gYWRk IFZNcyB5b3UgYW55d2F5IG5lZWQgYSBydW5uaW5nIGhvc3QgaW4gdGhlIGNsdXN0ZXIgd2hpY2gg bWVhbnMgdGhlIApjcHUgbmFtZSBhbmQgdGhlIGFyY2hpdGVjdHVyZSB3b3VsZCBiZSB0aGUgaG9z dCdzLgpTbyB3ZSBjYW4ga2VlcCB0aGUgY2x1c3RlciBhdHRyaWJ1dGVzIC0gImNwdSBuYW1lIiBh bmQgImFyY2giIGNvbnNpc3RlbnQgCmFuZCBhbGxvdyB0aGVtIHRvIGJlIGVtcHR5IG9uIGNyZWF0 aW9uLgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+IEVuZ2luZS1kZXZlbCBtYWlsaW5nIGxpc3QKPiBFbmdpbmUtZGV2ZWxAb3ZpcnQub3JnCj4g aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VuZ2luZS1kZXZlbAoKCi0t LS0tLS0tLS0tLS0tMDYwMzA4MDkwMzAzMDAwNDA1MDgwNjAwCkNvbnRlbnQtVHlwZTogdGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoK PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNP LTg4NTktMSIKICAgICAgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4KICA8L2hlYWQ+CiAgPGJv ZHkgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+CiAgICA8ZGl2IGNsYXNzPSJtb3ot Y2l0ZS1wcmVmaXgiPk9uIDA4LzMwLzIwMTMgMTA6NTEgUE0sIExlb25hcmRvCiAgICAgIEJpYW5j b25pIHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUKY2l0ZT0ibWlkOjUwRUIy MDIyNkI3MkQ2NDE5MzU2RkMzMjBBQjYyQjg3MTkxNzMzNzBAU0VSVjA3MC5jb3JwLmVsZG9yYWRv Lm9yZy5iciIKICAgICAgdHlwZT0iY2l0ZSI+CiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRl bnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOwogICAgICAgIGNoYXJzZXQ9SVNPLTg4NTktMSI+ CiAgICAgIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQg KGZpbHRlcmVkCiAgICAgICAgbWVkaXVtKSI+CiAgICAgIDxzdHlsZT48IS0tCi8qIEZvbnQgRGVm aW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7CglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9Ci8qIFN0eWxlIERlZmluaXRpb25zICovCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRv bTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9CmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpibHVlOwoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOnB1cnBsZTsKCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQpzcGFuLkVtYWlsU3R5bGUxNwoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJY29sb3I6d2luZG93 dGV4dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7Cglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQpAcGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3 MC44NXB0IDMuMGNtIDcwLjg1cHQgMy4wY207fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPgogICAgICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgogICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBldmVyeW9uZSE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+RHVyaW5nIHRoZSBkZXZlbG9wbWVudAogICAgICAgICAgICBv ZiBQUEM2NCBzdXBwb3J0IGluIHRoZSBlbmdpbmUsIHdlIGZhY2VkIHNvbWUgVVggaXNzdWVzCiAg ICAgICAgICAgIHJlZ2FyZGluZyB0aGUgZGVmYXVsdCBDbHVzdGVyICh0aGF0IENsdXN0ZXIgd2l0 aCBlbXB0eQogICAgICAgICAgICBwcm9jZXNzb3IgbmFtZSkuPG86cD48L286cD48L3NwYW4+PC9w PgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkN1cnJlbnRseSwgb1ZpcnQgZW5naW5lCiAgICAgICAgICAgIGFsbG93cyB0 aGUgZGVmYXVsdCBDbHVzdGVyIHRvIGNvbnRhaW4gZW1wdHkgcHJvY2Vzc29yIG5hbWUsCiAgICAg ICAgICAgIGFuZCB0aGUgYWRtaW5pc3RyYXRvciBjYW4gYWRkIFZNcyBhbmQvb3IgVGVtcGxhdGVz IHRvIGl0LgogICAgICAgICAgICBUaGUgcHJvY2Vzc29yIG5hbWUgY2FuIGJlIGFzc2lnbmVkIGxh dGVyLCBlZGl0aW5nIHRoZQogICAgICAgICAgICBjbHVzdGVyIG9yIGFzc2lnbmluZyBhIHZhbGlk IGhvc3QgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CiAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkR1cmluZyB0aGUK ICAgICAgICAgICAgaW1wbGVtZW50YXRpb24gb2YgUFBDNjQgc3VwcG9ydCBvbiB0aGUgZW5naW5l LCB0aGUgZmllbGQKICAgICAgICAgICAgJiM4MjIwO2FyY2hpdGVjdHVyZSYjODIyMDsgd2FzIGFk ZGVkIHRvIENsdXN0ZXJzLCBWTXMgYW5kIFRlbXBsYXRlcwogICAgICAgICAgICBlbnRpdGllcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28gd2UgaGF2ZSB0aGUgZm9sbG93aW5n CiAgICAgICAgICAgIHF1ZXN0aW9ucyByZWdhcmRpbmcgaG93IHRoZSBVSSBzaG91bGQgYmVoYXZl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFNoYWxsIHdlIGtlZXAgYWxsb3dp bmcKICAgICAgICAgICAgdGhlIGFkbWluaXN0cmF0b3IgdG8gYXNzaWduIFZNcyBhbmQgVGVtcGxh dGVzIHRvIHRoZSBDbHVzdGVyCiAgICAgICAgICAgIHdpdGggbm8gcHJvY2Vzc29yIG5hbWUgb3Ig YXNzaWduZWQgYXJjaGl0ZWN0dXJlID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtJmd0 OyBJZiB3ZQogICAgICAgICAgICBoYXZlIGFuICYjODIyMDt5ZXMmIzgyMjE7IGZvciB0aGUgcXVl c3Rpb24gYWJvdmU6PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gV2Ugd2lsbAogICAg ICAgICAgICBoYXZlIHRvIGFzc2lnbiB0aGUgYXJjaGl0ZWN0dXJlIHRvIHRoZSBDbHVzdGVyIGJh c2VkIG9uIHRoZQogICAgICAgICAgICBPUyBvZiB0aGUgZmlyc3QgYXNzaWduZWQgVk0sIGFuZCZu YnNwOyB0aGUgcHJvY2Vzc29yIG5hbWUgY291bGQKICAgICAgICAgICAgYmUgZGVmaW5lZCB0aGUg c2FtZSB3YXkgYXMgY3VycmVudGx5ICYjODIzMDsgZWRpdGluZyB0aGUgQ2x1c3RlcgogICAgICAg ICAgICBvciBhc3NpZ25pbmcgYSBjb21wYXRpYmxlIEhvc3QgdG8gaXQuPG86cD48L286cD48L3Nw YW4+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKICAg ICAgICAgICAgLS0gVGhlIFZNIGNyZWF0aW9uIHBvcHVwIHdpbGwgaGF2ZSB0byBiZSBhYmxlIHRv IGluZGljYXRlCiAgICAgICAgICAgIHRoZSBhcmNoaXRlY3R1cmUgb2YgZWFjaCBPUyAmIzgyMzA7 IHNvbWUgT1NlcyBoYXZlIHRoZSBzYW1lIG5hbWUsCiAgICAgICAgICAgIGFuZCBpdCBtYXkgZ2V0 IGFtYmlndW91cyBzaW5jZSB0aGUgQ2x1c3RlciBhcmNoaXRlY3R1cmUgaXMKICAgICAgICAgICAg c3RpbGwgdW5kZWZpbmVkIGF0IHRoYXQgcG9pbnQgKGJlZm9yZSB0aGUgZmlyc3QgVk0gZ2V0CiAg ICAgICAgICAgIGFscmVhZHkgY3JlYXRlZCkuPG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9v OnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMuPG86cD48L286cD48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGVvbmFyZG8gQmlhbmNvbmk8bzpwPjwv bzpwPjwvcD4KICAgICAgPC9kaXY+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+CiAgICBUbyBh ZGQgVk1zIHlvdSBhbnl3YXkgbmVlZCBhIHJ1bm5pbmcgaG9zdCBpbiB0aGUgY2x1c3RlciB3aGlj aCBtZWFucwogICAgdGhlIGNwdSBuYW1lIGFuZCB0aGUgYXJjaGl0ZWN0dXJlIHdvdWxkIGJlIHRo ZSBob3N0J3MuIDxicj4KICAgIFNvIHdlIGNhbiBrZWVwIHRoZSBjbHVzdGVyIGF0dHJpYnV0ZXMg LSAiY3B1IG5hbWUiIGFuZCAiYXJjaCIKICAgIGNvbnNpc3RlbnQgYW5kIGFsbG93IHRoZW0gdG8g YmUgZW1wdHkgb24gY3JlYXRpb24uIDxicj4KICAgIDxibG9ja3F1b3RlCmNpdGU9Im1pZDo1MEVC MjAyMjZCNzJENjQxOTM1NkZDMzIwQUI2MkI4NzE5MTczMzcwQFNFUlYwNzAuY29ycC5lbGRvcmFk by5vcmcuYnIiCiAgICAgIHR5cGU9ImNpdGUiPgogICAgICA8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPgogICAgICA8L2Rpdj4KICAgICAgPGJyPgogICAgICA8ZmllbGRzZXQgY2xhc3M9Im1pbWVB dHRhY2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PgogICAgICA8YnI+CiAgICAgIDxwcmUgd3JhcD0i Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpFbmdpbmUt ZGV2ZWwgbWFpbGluZyBsaXN0CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhy ZWY9Im1haWx0bzpFbmdpbmUtZGV2ZWxAb3ZpcnQub3JnIj5FbmdpbmUtZGV2ZWxAb3ZpcnQub3Jn PC9hPgo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vbGlzdHMu b3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vZW5naW5lLWRldmVsIj5odHRwOi8vbGlzdHMub3Zp cnQub3JnL21haWxtYW4vbGlzdGluZm8vZW5naW5lLWRldmVsPC9hPgo8L3ByZT4KICAgIDwvYmxv Y2txdW90ZT4KICAgIDxicj4KICA8L2JvZHk+CjwvaHRtbD4KCi0tLS0tLS0tLS0tLS0tMDYwMzA4 MDkwMzAzMDAwNDA1MDgwNjAwLS0K --===============3927011372483483895==-- From leonardo.bianconi at eldorado.org.br Mon Sep 2 08:35:31 2013 Content-Type: multipart/mixed; boundary="===============8220825391078381573==" MIME-Version: 1.0 From: Leonardo Bianconi To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Mon, 02 Sep 2013 12:35:27 +0000 Message-ID: <50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br> In-Reply-To: 5222F5B7.5060603@redhat.com --===============8220825391078381573== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > > From: Roy Golan [mailto:rgolan(a)redhat.com] = > > Sent: domingo, 1 de setembro de 2013 05:07 > > To: Leonardo Bianconi > > Cc: engine-devel(a)ovirt.org > > Subject: Re: [Engine-devel] Cluster default with empty processor name w= ith PPC64 support > > > > On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: > > Hi everyone! > > = > > During the development of PPC64 support in the engine, we faced some UX= issues regarding the default Cluster (that Cluster with empty processor na= me). > > = > > Currently, oVirt engine allows the default Cluster to contain empty pro= cessor name, and the administrator can add VMs and/or Templates to it. The = processor name can be assigned later, editing the cluster or assigning a va= lid host to it. > > = > > During the implementation of PPC64 support on the engine, the field "ar= chitecture" was added to Clusters, VMs and Templates entities. > > = > > So we have the following questions regarding how the UI should behave: > > = > > - Shall we keep allowing the administrator to assign VMs and Templates = to the Cluster with no processor name or assigned architecture ? > > -> If we have an "yes" for the question above: > > -- We will have to assign the architecture to the Cluster = based on the OS of the first assigned VM, and the processor name could be = defined the same way as currently ... editing the Cluster or assigning a co= mpatible Host to it. > > -- The VM creation popup will have to be a= ble to indicate the architecture of each OS ... some OSes have the same nam= e, and it may get ambiguous since the Cluster architecture is still undefin= ed at that point (before the first VM get already created). > > = > > Thanks! > > Regards. > > Leonardo Bianconi > > > To add VMs you anyway need a running host in the cluster which means the = cpu name and the architecture would be the host's. = > So we can keep the cluster attributes - "cpu name" and "arch" consistent = and allow them to be empty on creation. = > > Hi Roy! There is a way to add VMs in a cluster with no hosts running. Steps to repr= oduce: - Initialize the oVirt engine with a new data base - Create a new Cluster (I will call it of newCluster) in the Data Center De= fault - Add a host in the newCluster - Add a Storage - Create a VM in the Cluster Default Result: The system allows a VM in a cluster with no Hosts running in it. Is it a bug or a system functionality? If it's a functionality, the issue a= bove can happen. Thanks!! Regards. Leonardo Bianconi > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel --===============8220825391078381573==-- From iheim at redhat.com Mon Sep 2 09:28:49 2013 Content-Type: multipart/mixed; boundary="===============5342073984126343528==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Mon, 02 Sep 2013 16:28:38 +0300 Message-ID: <52249286.5010009@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br --===============5342073984126343528== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: > > >>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>> Sent: domingo, 1 de setembro de 2013 05:07 >>> To: Leonardo Bianconi >>> Cc: engine-devel(a)ovirt.org >>> Subject: Re: [Engine-devel] Cluster default with empty processor name w= ith PPC64 support >>> >>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>> Hi everyone! >>> >>> During the development of PPC64 support in the engine, we faced some UX= issues regarding the default Cluster (that Cluster with empty processor na= me). >>> >>> Currently, oVirt engine allows the default Cluster to contain empty pro= cessor name, and the administrator can add VMs and/or Templates to it. The = processor name can be assigned later, editing the cluster or assigning a va= lid host to it. >>> >>> During the implementation of PPC64 support on the engine, the field "ar= chitecture" was added to Clusters, VMs and Templates entities. >>> >>> So we have the following questions regarding how the UI should behave: >>> >>> - Shall we keep allowing the administrator to assign VMs and Templates = to the Cluster with no processor name or assigned architecture ? >>> -> If we have an "yes" for the question above: >>> -- We will have to assign the architecture to the Cluster= based on the OS of the first assigned VM, and the processor name could be= defined the same way as currently ... editing the Cluster or assigning a c= ompatible Host to it. >>> -- The VM creation popup will have to be = able to indicate the architecture of each OS ... some OSes have the same na= me, and it may get ambiguous since the Cluster architecture is still undefi= ned at that point (before the first VM get already created). >>> >>> Thanks! >>> Regards. >>> Leonardo Bianconi >>> >> To add VMs you anyway need a running host in the cluster which means the= cpu name and the architecture would be the host's. >> So we can keep the cluster attributes - "cpu name" and "arch" consistent= and allow them to be empty on creation. >> >> > Hi Roy! > > There is a way to add VMs in a cluster with no hosts running. Steps to re= produce: > - Initialize the oVirt engine with a new data base > - Create a new Cluster (I will call it of newCluster) in the Data Center = Default > - Add a host in the newCluster > - Add a Storage > - Create a VM in the Cluster Default > Result: The system allows a VM in a cluster with no Hosts running in it. > > Is it a bug or a system functionality? If it's a functionality, the issue= above can happen. while above can happen, is it really an interesting use case to solve? can user edit the arch field of a vm? if so, i'd just block running it = on incorrect cluster (just like we block on moving it between = incompatible clusters) until user fix the issue --===============5342073984126343528==-- From leonardo.bianconi at eldorado.org.br Mon Sep 2 11:43:07 2013 Content-Type: multipart/mixed; boundary="===============1052544882402616788==" MIME-Version: 1.0 From: Leonardo Bianconi To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Mon, 02 Sep 2013 15:43:03 +0000 Message-ID: <50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br> In-Reply-To: 52249286.5010009@redhat.com --===============1052544882402616788== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Itamar Heim [mailto:iheim(a)redhat.com] >Sent: segunda-feira, 2 de setembro de 2013 10:29 >To: Leonardo Bianconi >Cc: Roy Golan; engine-devel(a)ovirt.org >Subject: Re: [Engine-devel] Cluster default with empty processor name with= PPC64 support > >On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >> >> >>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>> To: Leonardo Bianconi >>>> Cc: engine-devel(a)ovirt.org >>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>> name with PPC64 support >>>> >>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>> Hi everyone! >>>> >>>> During the development of PPC64 support in the engine, we faced some U= X issues regarding the default Cluster (that Cluster with >empty processor name). >>>> >>>> Currently, oVirt engine allows the default Cluster to contain empty pr= ocessor name, and the administrator can add VMs and/or >Templates to it. The processor name can be assigned later, editing the clu= ster or assigning a valid host to it. >>>> >>>> During the implementation of PPC64 support on the engine, the field "a= rchitecture" was added to Clusters, VMs and Templates >entities. >>>> herdado >>>> So we have the following questions regarding how the UI should behave: >>>> >>>> - Shall we keep allowing the administrator to assign VMs and Templates= to the Cluster with no processor name or assigned >architecture ? >>>> -> If we have an "yes" for the question above: >>>> -- We will have to assign the architecture to the Cluste= r based on the OS of the first assigned VM, and the processor name >could be defined the same way as currently ... editing the Cluster or assi= gning a compatible Host to it. >>>> -- The VM creation popup will have to be= able to indicate the architecture of each OS ... some OSes have the same >name, and it may get ambiguous since the Cluster architecture is still und= efined at that point (before the first VM get already created). >>>> >>>> Thanks! >>>> Regards. >>>> Leonardo Bianconi >>>> >>> To add VMs you anyway need a running host in the cluster which means th= e cpu name and the architecture would be the host's. >>> So we can keep the cluster attributes - "cpu name" and "arch" consisten= t and allow them to be empty on creation. >>> >>> >> Hi Roy! >> >> There is a way to add VMs in a cluster with no hosts running. Steps to r= eproduce: >> - Initialize the oVirt engine with a new data base >> - Create a new Cluster (I will call it of newCluster) in the Data >> Center Default >> - Add a host in the newCluster >> - Add a Storage >> - Create a VM in the Cluster Default >> Result: The system allows a VM in a cluster with no Hosts running in it. >> >> Is it a bug or a system functionality? If it's a functionality, the issu= e above can happen. > >while above can happen, is it really an interesting use case to solve? >can user edit the arch field of a vm? if so, i'd just block running it on = incorrect cluster (just like we block on moving it between >incompatible clusters) until user fix the issue Yes, it's interesting solve, because we use the cluster architecture when c= reating VMs. The user cannot edit the arch field, because there is no field for that, it= is inherited from the cluster. The arch is important on creating VMs, beca= use it filters the OS list and defines the VM architecture. What should we do? Thanks!! --===============1052544882402616788==-- From iheim at redhat.com Mon Sep 2 12:46:03 2013 Content-Type: multipart/mixed; boundary="===============6028355047069922606==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Mon, 02 Sep 2013 19:45:57 +0300 Message-ID: <5224C0C5.1030100@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B8719173455@SERV070.corp.eldorado.org.br --===============6028355047069922606== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/02/2013 06:43 PM, Leonardo Bianconi wrote: > > >> -----Original Message----- >> From: Itamar Heim [mailto:iheim(a)redhat.com] >> Sent: segunda-feira, 2 de setembro de 2013 10:29 >> To: Leonardo Bianconi >> Cc: Roy Golan; engine-devel(a)ovirt.org >> Subject: Re: [Engine-devel] Cluster default with empty processor name wi= th PPC64 support >> >> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>> >>> >>>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>> To: Leonardo Bianconi >>>>> Cc: engine-devel(a)ovirt.org >>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>> name with PPC64 support >>>>> >>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>> Hi everyone! >>>>> >>>>> During the development of PPC64 support in the engine, we faced some = UX issues regarding the default Cluster (that Cluster with >> empty processor name). >>>>> >>>>> Currently, oVirt engine allows the default Cluster to contain empty p= rocessor name, and the administrator can add VMs and/or >> Templates to it. The processor name can be assigned later, editing the c= luster or assigning a valid host to it. >>>>> >>>>> During the implementation of PPC64 support on the engine, the field "= architecture" was added to Clusters, VMs and Templates >> entities. >>>>> herdado >>>>> So we have the following questions regarding how the UI should behave: >>>>> >>>>> - Shall we keep allowing the administrator to assign VMs and Template= s to the Cluster with no processor name or assigned >> architecture ? >>>>> -> If we have an "yes" for the question above: >>>>> -- We will have to assign the architecture to the Clus= ter based on the OS of the first assigned VM, and the processor name >> could be defined the same way as currently ... editing the Cluster or as= signing a compatible Host to it. >>>>> -- The VM creation popup will have to = be able to indicate the architecture of each OS ... some OSes have the same >> name, and it may get ambiguous since the Cluster architecture is still u= ndefined at that point (before the first VM get already created). >>>>> >>>>> Thanks! >>>>> Regards. >>>>> Leonardo Bianconi >>>>> >>>> To add VMs you anyway need a running host in the cluster which means t= he cpu name and the architecture would be the host's. >>>> So we can keep the cluster attributes - "cpu name" and "arch" consiste= nt and allow them to be empty on creation. >>>> >>>> >>> Hi Roy! >>> >>> There is a way to add VMs in a cluster with no hosts running. Steps to = reproduce: >>> - Initialize the oVirt engine with a new data base >>> - Create a new Cluster (I will call it of newCluster) in the Data >>> Center Default >>> - Add a host in the newCluster >>> - Add a Storage >>> - Create a VM in the Cluster Default >>> Result: The system allows a VM in a cluster with no Hosts running in it. >>> >>> Is it a bug or a system functionality? If it's a functionality, the iss= ue above can happen. >> >> while above can happen, is it really an interesting use case to solve? >> can user edit the arch field of a vm? if so, i'd just block running it o= n incorrect cluster (just like we block on moving it between >> incompatible clusters) until user fix the issue > > Yes, it's interesting solve, because we use the cluster architecture when= creating VMs. > The user cannot edit the arch field, because there is no field for that, = it is inherited from the cluster. The arch is important on creating VMs, be= cause it filters the OS list and defines the VM architecture. > What should we do? > > Thanks!! > so worst case the list is not filtered while creating the VM for that = corner case? thinking about this some more, with all due respect to PPC and this = corner case, I'd just assume if cluster arch is not yet defined, OS list = should be filtered as x86_64. or, we block creating VMs on clusters which have no arch defined (I'm = specifically not saying no hosts, just in case its useful somehow) --===============6028355047069922606==-- From leonardo.bianconi at eldorado.org.br Tue Sep 3 07:39:28 2013 Content-Type: multipart/mixed; boundary="===============6447307165324511247==" MIME-Version: 1.0 From: Leonardo Bianconi To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Tue, 03 Sep 2013 11:39:18 +0000 Message-ID: <50EB20226B72D6419356FC320AB62B8719173508@SERV070.corp.eldorado.org.br> In-Reply-To: 5224C0C5.1030100@redhat.com --===============6447307165324511247== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Itamar Heim [mailto:iheim(a)redhat.com] >Sent: segunda-feira, 2 de setembro de 2013 13:46 >To: Leonardo Bianconi >Cc: Roy Golan; engine-devel(a)ovirt.org >Subject: Re: [Engine-devel] Cluster default with empty processor name with= PPC64 support > >On 09/02/2013 06:43 PM, Leonardo Bianconi wrote: >> >> >>> -----Original Message----- >>> From: Itamar Heim [mailto:iheim(a)redhat.com] >>> Sent: segunda-feira, 2 de setembro de 2013 10:29 >>> To: Leonardo Bianconi >>> Cc: Roy Golan; engine-devel(a)ovirt.org >>> Subject: Re: [Engine-devel] Cluster default with empty processor name >>> with PPC64 support >>> >>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>>> >>>> >>>>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>>> To: Leonardo Bianconi >>>>>> Cc: engine-devel(a)ovirt.org >>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>>> name with PPC64 support >>>>>> >>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>>> Hi everyone! >>>>>> >>>>>> During the development of PPC64 support in the engine, we faced >>>>>> some UX issues regarding the default Cluster (that Cluster with >>> empty processor name). >>>>>> >>>>>> Currently, oVirt engine allows the default Cluster to contain >>>>>> empty processor name, and the administrator can add VMs and/or >>> Templates to it. The processor name can be assigned later, editing the = cluster or assigning a valid host to it. >>>>>> >>>>>> During the implementation of PPC64 support on the engine, the >>>>>> field "architecture" was added to Clusters, VMs and Templates >>> entities. >>>>>> herdado >>>>>> So we have the following questions regarding how the UI should behav= e: >>>>>> >>>>>> - Shall we keep allowing the administrator to assign VMs and >>>>>> Templates to the Cluster with no processor name or assigned >>> architecture ? >>>>>> -> If we have an "yes" for the question above: >>>>>> -- We will have to assign the architecture to the >>>>>> Cluster based on the OS of the first assigned VM, and the >>>>>> processor name >>> could be defined the same way as currently ... editing the Cluster or a= ssigning a compatible Host to it. >>>>>> -- The VM creation popup will have >>>>>> to be able to indicate the architecture of each OS ... some OSes >>>>>> have the same >>> name, and it may get ambiguous since the Cluster architecture is still = undefined at that point (before the first VM get already >created). >>>>>> >>>>>> Thanks! >>>>>> Regards. >>>>>> Leonardo Bianconi >>>>>> >>>>> To add VMs you anyway need a running host in the cluster which means = the cpu name and the architecture would be the host's. >>>>> So we can keep the cluster attributes - "cpu name" and "arch" consist= ent and allow them to be empty on creation. >>>>> >>>>> >>>> Hi Roy! >>>> >>>> There is a way to add VMs in a cluster with no hosts running. Steps to= reproduce: >>>> - Initialize the oVirt engine with a new data base >>>> - Create a new Cluster (I will call it of newCluster) in the Data >>>> Center Default >>>> - Add a host in the newCluster >>>> - Add a Storage >>>> - Create a VM in the Cluster Default >>>> Result: The system allows a VM in a cluster with no Hosts running in i= t. >>>> >>>> Is it a bug or a system functionality? If it's a functionality, the is= sue above can happen. >>> >>> while above can happen, is it really an interesting use case to solve? >>> can user edit the arch field of a vm? if so, i'd just block running >>> it on incorrect cluster (just like we block on moving it between >>> incompatible clusters) until user fix the issue >> >> Yes, it's interesting solve, because we use the cluster architecture whe= n creating VMs. >> The user cannot edit the arch field, because there is no field for that,= it is inherited from the cluster. The arch is important on >creating VMs, because it filters the OS list and defines the VM architectu= re. >> What should we do? >> >> Thanks!! >> > >so worst case the list is not filtered while creating the VM for that corn= er case? > >thinking about this some more, with all due respect to PPC and this corner= case, I'd just assume if cluster arch is not yet defined, OS list >should be filtered as x86_64. >or, we block creating VMs on clusters which have no arch defined (I'm spec= ifically not saying no hosts, just in case its useful somehow) I think both are good solutions, but looking the system behavior, I think t= he first solution will be weird for new users and the second has problems w= hen upgrading the data base. I would suggest the following behavior: 1. For new data bases: Block the admin to add VMs in the cluster with no pr= ocessor name (Cluster Default), i. e. no architecture. 2. For upgraded data bases, If the cluster with no processor name (Cluster = Default) has: 2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it= as x86_64. 2.2 - no VMs: Keep the cluster with no processor name, i. e. no architect= ure (it will keep the same behavior of the cluster for new data base - item= 1) On the item 2.1, when setting the architecture of the cluster (Cluster Defa= ult) for x86_64, the processor name will be empty. Should we set it for the= lowest x86_64 level? What do you think? Thanks!! --===============6447307165324511247==-- From iheim at redhat.com Tue Sep 3 07:49:59 2013 Content-Type: multipart/mixed; boundary="===============4648779151029776914==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Tue, 03 Sep 2013 14:49:53 +0300 Message-ID: <5225CCE1.5010909@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B8719173508@SERV070.corp.eldorado.org.br --===============4648779151029776914== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/03/2013 02:39 PM, Leonardo Bianconi wrote: > > >> -----Original Message----- >> From: Itamar Heim [mailto:iheim(a)redhat.com] >> Sent: segunda-feira, 2 de setembro de 2013 13:46 >> To: Leonardo Bianconi >> Cc: Roy Golan; engine-devel(a)ovirt.org >> Subject: Re: [Engine-devel] Cluster default with empty processor name wi= th PPC64 support >> >> On 09/02/2013 06:43 PM, Leonardo Bianconi wrote: >>> >>> >>>> -----Original Message----- >>>> From: Itamar Heim [mailto:iheim(a)redhat.com] >>>> Sent: segunda-feira, 2 de setembro de 2013 10:29 >>>> To: Leonardo Bianconi >>>> Cc: Roy Golan; engine-devel(a)ovirt.org >>>> Subject: Re: [Engine-devel] Cluster default with empty processor name >>>> with PPC64 support >>>> >>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>>>> >>>>> >>>>>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>>>> To: Leonardo Bianconi >>>>>>> Cc: engine-devel(a)ovirt.org >>>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>>>> name with PPC64 support >>>>>>> >>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>>>> Hi everyone! >>>>>>> >>>>>>> During the development of PPC64 support in the engine, we faced >>>>>>> some UX issues regarding the default Cluster (that Cluster with >>>> empty processor name). >>>>>>> >>>>>>> Currently, oVirt engine allows the default Cluster to contain >>>>>>> empty processor name, and the administrator can add VMs and/or >>>> Templates to it. The processor name can be assigned later, editing the= cluster or assigning a valid host to it. >>>>>>> >>>>>>> During the implementation of PPC64 support on the engine, the >>>>>>> field "architecture" was added to Clusters, VMs and Templates >>>> entities. >>>>>>> herdado >>>>>>> So we have the following questions regarding how the UI should beha= ve: >>>>>>> >>>>>>> - Shall we keep allowing the administrator to assign VMs and >>>>>>> Templates to the Cluster with no processor name or assigned >>>> architecture ? >>>>>>> -> If we have an "yes" for the question above: >>>>>>> -- We will have to assign the architecture to the >>>>>>> Cluster based on the OS of the first assigned VM, and the >>>>>>> processor name >>>> could be defined the same way as currently ... editing the Cluster or = assigning a compatible Host to it. >>>>>>> -- The VM creation popup will have >>>>>>> to be able to indicate the architecture of each OS ... some OSes >>>>>>> have the same >>>> name, and it may get ambiguous since the Cluster architecture is still= undefined at that point (before the first VM get already >> created). >>>>>>> >>>>>>> Thanks! >>>>>>> Regards. >>>>>>> Leonardo Bianconi >>>>>>> >>>>>> To add VMs you anyway need a running host in the cluster which means= the cpu name and the architecture would be the host's. >>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consis= tent and allow them to be empty on creation. >>>>>> >>>>>> >>>>> Hi Roy! >>>>> >>>>> There is a way to add VMs in a cluster with no hosts running. Steps t= o reproduce: >>>>> - Initialize the oVirt engine with a new data base >>>>> - Create a new Cluster (I will call it of newCluster) in the Data >>>>> Center Default >>>>> - Add a host in the newCluster >>>>> - Add a Storage >>>>> - Create a VM in the Cluster Default >>>>> Result: The system allows a VM in a cluster with no Hosts running in = it. >>>>> >>>>> Is it a bug or a system functionality? If it's a functionality, the i= ssue above can happen. >>>> >>>> while above can happen, is it really an interesting use case to solve? >>>> can user edit the arch field of a vm? if so, i'd just block running >>>> it on incorrect cluster (just like we block on moving it between >>>> incompatible clusters) until user fix the issue >>> >>> Yes, it's interesting solve, because we use the cluster architecture wh= en creating VMs. >>> The user cannot edit the arch field, because there is no field for that= , it is inherited from the cluster. The arch is important on >> creating VMs, because it filters the OS list and defines the VM architec= ture. >>> What should we do? >>> >>> Thanks!! >>> >> >> so worst case the list is not filtered while creating the VM for that co= rner case? >> >> thinking about this some more, with all due respect to PPC and this corn= er case, I'd just assume if cluster arch is not yet defined, OS list >> should be filtered as x86_64. >> or, we block creating VMs on clusters which have no arch defined (I'm sp= ecifically not saying no hosts, just in case its useful somehow) > > I think both are good solutions, but looking the system behavior, I think= the first solution will be weird for new users and the second has problems= when upgrading the data base. > I would suggest the following behavior: > > 1. For new data bases: Block the admin to add VMs in the cluster with no = processor name (Cluster Default), i. e. no architecture. > 2. For upgraded data bases, If the cluster with no processor name (Cluste= r Default) has: > 2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use= it as x86_64. > 2.2 - no VMs: Keep the cluster with no processor name, i. e. no archit= ecture (it will keep the same behavior of the cluster for new data base - i= tem 1) > > On the item 2.1, when setting the architecture of the cluster (Cluster De= fault) for x86_64, the processor name will be empty. Should we set it for t= he lowest x86_64 level? > > What do you think? > > Thanks!! > sounds good to me. roy/omer/michal? --===============4648779151029776914==-- From rgolan at redhat.com Wed Sep 4 06:07:50 2013 Content-Type: multipart/mixed; boundary="===============1617198286663878792==" MIME-Version: 1.0 From: Roy Golan To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Wed, 04 Sep 2013 13:07:43 +0300 Message-ID: <5227066F.7060509@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br --===============1617198286663878792== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>> Sent: domingo, 1 de setembro de 2013 05:07 >>> To: Leonardo Bianconi >>> Cc:engine-devel(a)ovirt.org >>> Subject: Re: [Engine-devel] Cluster default with empty processor name w= ith PPC64 support >>> >>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>> Hi everyone! >>> = >>> During the development of PPC64 support in the engine, we faced some UX= issues regarding the default Cluster (that Cluster with empty processor na= me). >>> = >>> Currently, oVirt engine allows the default Cluster to contain empty pro= cessor name, and the administrator can add VMs and/or Templates to it. The = processor name can be assigned later, editing the cluster or assigning a va= lid host to it. >>> = >>> During the implementation of PPC64 support on the engine, the field "ar= chitecture" was added to Clusters, VMs and Templates entities. >>> = >>> So we have the following questions regarding how the UI should behave: >>> = >>> - Shall we keep allowing the administrator to assign VMs and Templates = to the Cluster with no processor name or assigned architecture ? >>> -> If we have an "yes" for the question above: >>> -- We will have to assign the architecture to the Cluster= based on the OS of the first assigned VM, and the processor name could be= defined the same way as currently ... editing the Cluster or assigning a c= ompatible Host to it. >>> -- The VM creation popup will have to be = able to indicate the architecture of each OS ... some OSes have the same na= me, and it may get ambiguous since the Cluster architecture is still undefi= ned at that point (before the first VM get already created). >>> = >>> Thanks! >>> Regards. >>> Leonardo Bianconi >>> >> To add VMs you anyway need a running host in the cluster which means the= cpu name and the architecture would be the host's. >> So we can keep the cluster attributes - "cpu name" and "arch" consistent= and allow them to be empty on creation. >> >> > Hi Roy! > > There is a way to add VMs in a cluster with no hosts running. Steps to re= produce: > - Initialize the oVirt engine with a new data base > - Create a new Cluster (I will call it of newCluster) in the Data Center = Default > - Add a host in the newCluster > - Add a Storage > - Create a VM in the Cluster Default > Result: The system allows a VM in a cluster with no Hosts running in it. > > Is it a bug or a system functionality? If it's a functionality, the issue= above can happen. Just to clear this one - its a functional thing. its a bit confusing but = not too complicated: Storage and all its related actions/entities are related to the Data = Center (aka, code-wise storage pool). Its possible to create a VM once the DC is up, without a cluster i.e also provision = disks to it and so on. Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, = network config (also has a DC part though) and various other vars, must = be homogeneous in order for VMs to migrate between hosts. So cluster isn't really fully = configured till it has at least 1 host up. hope this make things clearer > Thanks!! > Regards. > Leonardo Bianconi >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel --===============1617198286663878792==-- From rgolan at redhat.com Wed Sep 4 07:13:28 2013 Content-Type: multipart/mixed; boundary="===============0811477696110410292==" MIME-Version: 1.0 From: Roy Golan To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Wed, 04 Sep 2013 14:13:22 +0300 Message-ID: <522715D2.8080103@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B87191733F5@SERV070.corp.eldorado.org.br --===============0811477696110410292== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: > >>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>> Sent: domingo, 1 de setembro de 2013 05:07 >>> To: Leonardo Bianconi >>> Cc: engine-devel(a)ovirt.org >>> Subject: Re: [Engine-devel] Cluster default with empty processor name w= ith PPC64 support >>> >>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>> Hi everyone! >>> = >>> During the development of PPC64 support in the engine, we faced some UX= issues regarding the default Cluster (that Cluster with empty processor na= me). >>> = >>> Currently, oVirt engine allows the default Cluster to contain empty pro= cessor name, and the administrator can add VMs and/or Templates to it. The = processor name can be assigned later, editing the cluster or assigning a va= lid host to it. >>> = >>> During the implementation of PPC64 support on the engine, the field "ar= chitecture" was added to Clusters, VMs and Templates entities. >>> = >>> So we have the following questions regarding how the UI should behave: >>> = >>> - Shall we keep allowing the administrator to assign VMs and Templates = to the Cluster with no processor name or assigned architecture ? >>> -> If we have an "yes" for the question above: >>> -- We will have to assign the architecture to the Cluster= based on the OS of the first assigned VM, and the processor name could be= defined the same way as currently ... editing the Cluster or assigning a c= ompatible Host to it. >>> -- The VM creation popup will have to be = able to indicate the architecture of each OS ... some OSes have the same na= me, and it may get ambiguous since the Cluster architecture is still undefi= ned at that point (before the first VM get already created). >>> = >>> Thanks! >>> Regards. >>> Leonardo Bianconi >>> >> To add VMs you anyway need a running host in the cluster which means the= cpu name and the architecture would be the host's. >> So we can keep the cluster attributes - "cpu name" and "arch" consistent= and allow them to be empty on creation. >> >> > Hi Roy! > > There is a way to add VMs in a cluster with no hosts running. Steps to re= produce: > - Initialize the oVirt engine with a new data base > - Create a new Cluster (I will call it of newCluster) in the Data Center = Default > - Add a host in the newCluster > - Add a Storage > - Create a VM in the Cluster Default > Result: The system allows a VM in a cluster with no Hosts running in it. > > Is it a bug or a system functionality? If it's a functionality, the issue= above can happen. Just to clear this one - its a functional thing. its a bit confusing but = not too complicated: Storage and all its related actions/entities are related to the Data = Center (aka, code-wise storage pool). Its possible to create a VM once the DC is up, without a cluster i.e also provision = disks to it and so on. Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, = network config etc, must be homogeneous in order for VMs to migrate between hosts which means we must have a running = cluster i.e at least 1 running host in it. > > Thanks!! > Regards. > Leonardo Bianconi >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel --===============0811477696110410292==-- From leonardo.bianconi at eldorado.org.br Wed Sep 4 08:50:12 2013 Content-Type: multipart/mixed; boundary="===============6642778098234639330==" MIME-Version: 1.0 From: Leonardo Bianconi To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Wed, 04 Sep 2013 12:50:02 +0000 Message-ID: <50EB20226B72D6419356FC320AB62B8719173649@SERV070.corp.eldorado.org.br> In-Reply-To: 522715D2.8080103@redhat.com --===============6642778098234639330== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: Roy Golan [mailto:rgolan(a)redhat.com] >Sent: quarta-feira, 4 de setembro de 2013 08:13 >To: Leonardo Bianconi >Cc: engine-devel(a)ovirt.org >Subject: Re: [Engine-devel] Cluster default with empty processor name with= PPC64 support > >On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >> >>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>> To: Leonardo Bianconi >>>> Cc: engine-devel(a)ovirt.org >>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>> name with PPC64 support >>>> >>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>> Hi everyone! >>>> >>>> During the development of PPC64 support in the engine, we faced some U= X issues regarding the default Cluster (that Cluster with >empty processor name). >>>> >>>> Currently, oVirt engine allows the default Cluster to contain empty pr= ocessor name, and the administrator can add VMs and/or >Templates to it. The processor name can be assigned later, editing the clu= ster or assigning a valid host to it. >>>> >>>> During the implementation of PPC64 support on the engine, the field "a= rchitecture" was added to Clusters, VMs and Templates >entities. >>>> >>>> So we have the following questions regarding how the UI should behave: >>>> >>>> - Shall we keep allowing the administrator to assign VMs and Templates= to the Cluster with no processor name or assigned >architecture ? >>>> -> If we have an "yes" for the question above: >>>> -- We will have to assign the architecture to the Cluste= r based on the OS of the first assigned VM, and the processor name >could be defined the same way as currently ... editing the Cluster or assi= gning a compatible Host to it. >>>> -- The VM creation popup will have to be= able to indicate the architecture of each OS ... some OSes have the same >name, and it may get ambiguous since the Cluster architecture is still und= efined at that point (before the first VM get already created). >>>> >>>> Thanks! >>>> Regards. >>>> Leonardo Bianconi >>>> >>> To add VMs you anyway need a running host in the cluster which means th= e cpu name and the architecture would be the host's. >>> So we can keep the cluster attributes - "cpu name" and "arch" consisten= t and allow them to be empty on creation. >>> >>> >> Hi Roy! >> >> There is a way to add VMs in a cluster with no hosts running. Steps to r= eproduce: >> - Initialize the oVirt engine with a new data base >> - Create a new Cluster (I will call it of newCluster) in the Data >> Center Default >> - Add a host in the newCluster >> - Add a Storage >> - Create a VM in the Cluster Default >> Result: The system allows a VM in a cluster with no Hosts running in it. >> >> Is it a bug or a system functionality? If it's a functionality, the issu= e above can happen. >Just to clear this one - its a functional thing. its a bit confusing but n= ot too complicated: > >Storage and all its related actions/entities are related to the Data Cente= r (aka, code-wise storage pool). Its possible to create a VM >once the DC is up, without a cluster i.e also provision disks to it and so= on. > >Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, netw= ork config etc, must be homogeneous in order for VMs to >migrate between hosts which means we must have a running cluster i.e at le= ast 1 running host in it. > Roy, thank you for the explanation! It`s clear now > >> >> Thanks!! >> Regards. >> Leonardo Bianconi >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel --===============6642778098234639330==-- From iheim at redhat.com Sun Sep 29 07:55:41 2013 Content-Type: multipart/mixed; boundary="===============9221029883846577737==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support Date: Sun, 29 Sep 2013 14:55:33 +0300 Message-ID: <52481535.1040004@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B8719173649@SERV070.corp.eldorado.org.br --===============9221029883846577737== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/04/2013 03:50 PM, Leonardo Bianconi wrote: > > >> -----Original Message----- >> From: Roy Golan [mailto:rgolan(a)redhat.com] >> Sent: quarta-feira, 4 de setembro de 2013 08:13 >> To: Leonardo Bianconi >> Cc: engine-devel(a)ovirt.org >> Subject: Re: [Engine-devel] Cluster default with empty processor name wi= th PPC64 support >> >> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>> >>>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>> To: Leonardo Bianconi >>>>> Cc: engine-devel(a)ovirt.org >>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>> name with PPC64 support >>>>> >>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>> Hi everyone! >>>>> >>>>> During the development of PPC64 support in the engine, we faced some = UX issues regarding the default Cluster (that Cluster with >> empty processor name). >>>>> >>>>> Currently, oVirt engine allows the default Cluster to contain empty p= rocessor name, and the administrator can add VMs and/or >> Templates to it. The processor name can be assigned later, editing the c= luster or assigning a valid host to it. >>>>> >>>>> During the implementation of PPC64 support on the engine, the field "= architecture" was added to Clusters, VMs and Templates >> entities. >>>>> >>>>> So we have the following questions regarding how the UI should behave: >>>>> >>>>> - Shall we keep allowing the administrator to assign VMs and Template= s to the Cluster with no processor name or assigned >> architecture ? >>>>> -> If we have an "yes" for the question above: >>>>> -- We will have to assign the architecture to the Clus= ter based on the OS of the first assigned VM, and the processor name >> could be defined the same way as currently ... editing the Cluster or as= signing a compatible Host to it. >>>>> -- The VM creation popup will have to = be able to indicate the architecture of each OS ... some OSes have the same >> name, and it may get ambiguous since the Cluster architecture is still u= ndefined at that point (before the first VM get already created). >>>>> >>>>> Thanks! >>>>> Regards. >>>>> Leonardo Bianconi >>>>> >>>> To add VMs you anyway need a running host in the cluster which means t= he cpu name and the architecture would be the host's. >>>> So we can keep the cluster attributes - "cpu name" and "arch" consiste= nt and allow them to be empty on creation. >>>> >>>> >>> Hi Roy! >>> >>> There is a way to add VMs in a cluster with no hosts running. Steps to = reproduce: >>> - Initialize the oVirt engine with a new data base >>> - Create a new Cluster (I will call it of newCluster) in the Data >>> Center Default >>> - Add a host in the newCluster >>> - Add a Storage >>> - Create a VM in the Cluster Default >>> Result: The system allows a VM in a cluster with no Hosts running in it. >>> >>> Is it a bug or a system functionality? If it's a functionality, the iss= ue above can happen. >> Just to clear this one - its a functional thing. its a bit confusing but= not too complicated: >> >> Storage and all its related actions/entities are related to the Data Cen= ter (aka, code-wise storage pool). Its possible to create a VM >> once the DC is up, without a cluster i.e also provision disks to it and = so on. >> >> Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, ne= twork config etc, must be homogeneous in order for VMs to >> migrate between hosts which means we must have a running cluster i.e at = least 1 running host in it. >> > Roy, thank you for the explanation! It`s clear now >> >>> >>> Thanks!! >>> Regards. >>> Leonardo Bianconi Leonardo - slightly related - is this ppc big endian, small endian? any = thoughts on current and future plans around endianes? also, can you help with my, well, ignorance - are ppc7+/ppc8[1] a newer = cpu level, also not backward compatible, etc.? Thanks, Itamar [1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html (courtesy of rich jones) --===============9221029883846577737==-- From leonardo.bianconi at eldorado.org.br Tue Oct 8 14:25:38 2013 Content-Type: multipart/mixed; boundary="===============4849293558270842857==" MIME-Version: 1.0 From: Leonardo Bianconi To: devel at ovirt.org Subject: [Engine-devel] RES: Cluster default with empty processor name with PPC64 support Date: Tue, 08 Oct 2013 18:25:33 +0000 Message-ID: <50EB20226B72D6419356FC320AB62B871917E364@SERV070.corp.eldorado.org.br> In-Reply-To: 52481535.1040004@redhat.com --===============4849293558270842857== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ________________________________________ De: Itamar Heim [iheim(a)redhat.com] Enviado: domingo, 29 de setembro de 2013 8:55 Para: Leonardo Bianconi Cc: Roy Golan; engine-devel(a)ovirt.org Assunto: Re: [Engine-devel] Cluster default with empty processor name with = PPC64 support On 09/04/2013 03:50 PM, Leonardo Bianconi wrote: > > >> -----Original Message----- >> From: Roy Golan [mailto:rgolan(a)redhat.com] >> Sent: quarta-feira, 4 de setembro de 2013 08:13 >> To: Leonardo Bianconi >> Cc: engine-devel(a)ovirt.org >> Subject: Re: [Engine-devel] Cluster default with empty processor name wi= th PPC64 support >> >> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>> >>>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>> To: Leonardo Bianconi >>>>> Cc: engine-devel(a)ovirt.org >>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>> name with PPC64 support >>>>> >>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>> Hi everyone! >>>>> >>>>> During the development of PPC64 support in the engine, we faced some = UX issues regarding the default Cluster (that Cluster with >> empty processor name). >>>>> >>>>> Currently, oVirt engine allows the default Cluster to contain empty p= rocessor name, and the administrator can add VMs and/or >> Templates to it. The processor name can be assigned later, editing the c= luster or assigning a valid host to it. >>>>> >>>>> During the implementation of PPC64 support on the engine, the field "= architecture" was added to Clusters, VMs and Templates >> entities. >>>>> >>>>> So we have the following questions regarding how the UI should behave: >>>>> >>>>> - Shall we keep allowing the administrator to assign VMs and Template= s to the Cluster with no processor name or assigned >> architecture ? >>>>> -> If we have an "yes" for the question above: >>>>> -- We will have to assign the architecture to the Clus= ter based on the OS of the first assigned VM, and the processor name >> could be defined the same way as currently ... editing the Cluster or as= signing a compatible Host to it. >>>>> -- The VM creation popup will have to = be able to indicate the architecture of each OS ... some OSes have the same >> name, and it may get ambiguous since the Cluster architecture is still u= ndefined at that point (before the first VM get already created). >>>>> >>>>> Thanks! >>>>> Regards. >>>>> Leonardo Bianconi >>>>> >>>> To add VMs you anyway need a running host in the cluster which means t= he cpu name and the architecture would be the host's. >>>> So we can keep the cluster attributes - "cpu name" and "arch" consiste= nt and allow them to be empty on creation. >>>> >>>> >>> Hi Roy! >>> >>> There is a way to add VMs in a cluster with no hosts running. Steps to = reproduce: >>> - Initialize the oVirt engine with a new data base >>> - Create a new Cluster (I will call it of newCluster) in the Data >>> Center Default >>> - Add a host in the newCluster >>> - Add a Storage >>> - Create a VM in the Cluster Default >>> Result: The system allows a VM in a cluster with no Hosts running in it. >>> >>> Is it a bug or a system functionality? If it's a functionality, the iss= ue above can happen. >> Just to clear this one - its a functional thing. its a bit confusing but= not too complicated: >> >> Storage and all its related actions/entities are related to the Data Cen= ter (aka, code-wise storage pool). Its possible to create a VM >> once the DC is up, without a cluster i.e also provision disks to it and = so on. >> >> Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, ne= twork config etc, must be homogeneous in order for VMs to >> migrate between hosts which means we must have a running cluster i.e at = least 1 running host in it. >> > Roy, thank you for the explanation! It`s clear now >> >>> >>> Thanks!! >>> Regards. >>> Leonardo Bianconi Hi Itamar, sorry about the late replay. > Leonardo - slightly related - is this ppc big endian, small endian? any > thoughts on current and future plans around endianes? PPC64 is big endian, but they are working to enable little endian. > also, can you help with my, well, ignorance - are ppc7+/ppc8[1] a newer > cpu level, also not backward compatible, etc.? Yes, Power7 and Power8 are different on family of processors. On the oVirt = wiki, pinatti, from IBM, wrote that the CPUs wouldn't be compatible with ea= ch other, so I asked him about the backward compatibility and he answered t= hey don't know what will be the compatibility level between Power7 and Powe= r8. More information about Power8 can be found here in http://www.pcworld.com/a= rticle/2047733/ibms-power8-opens-up-to-component-makers.html > Thanks, > Itamar > [1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html > (courtesy of rich jones) --===============4849293558270842857==-- From iheim at redhat.com Tue Oct 8 14:34:21 2013 Content-Type: multipart/mixed; boundary="===============8348470004514413820==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] RES: Cluster default with empty processor name with PPC64 support Date: Tue, 08 Oct 2013 21:34:16 +0300 Message-ID: <52545028.6050101@redhat.com> In-Reply-To: 50EB20226B72D6419356FC320AB62B871917E364@SERV070.corp.eldorado.org.br --===============8348470004514413820== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 10/08/2013 09:25 PM, Leonardo Bianconi wrote: > > ________________________________________ > De: Itamar Heim [iheim(a)redhat.com] > Enviado: domingo, 29 de setembro de 2013 8:55 > Para: Leonardo Bianconi > Cc: Roy Golan; engine-devel(a)ovirt.org > Assunto: Re: [Engine-devel] Cluster default with empty processor name wit= h PPC64 support > On 09/04/2013 03:50 PM, Leonardo Bianconi wrote: >> >> >>> -----Original Message----- >>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>> Sent: quarta-feira, 4 de setembro de 2013 08:13 >>> To: Leonardo Bianconi >>> Cc: engine-devel(a)ovirt.org >>> Subject: Re: [Engine-devel] Cluster default with empty processor name w= ith PPC64 support >>> >>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>>> >>>>>> From: Roy Golan [mailto:rgolan(a)redhat.com] >>>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>>> To: Leonardo Bianconi >>>>>> Cc: engine-devel(a)ovirt.org >>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>>> name with PPC64 support >>>>>> >>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>>> Hi everyone! >>>>>> >>>>>> During the development of PPC64 support in the engine, we faced some= UX issues regarding the default Cluster (that Cluster with >>> empty processor name). >>>>>> >>>>>> Currently, oVirt engine allows the default Cluster to contain empty = processor name, and the administrator can add VMs and/or >>> Templates to it. The processor name can be assigned later, editing the = cluster or assigning a valid host to it. >>>>>> >>>>>> During the implementation of PPC64 support on the engine, the field = "architecture" was added to Clusters, VMs and Templates >>> entities. >>>>>> >>>>>> So we have the following questions regarding how the UI should behav= e: >>>>>> >>>>>> - Shall we keep allowing the administrator to assign VMs and Templat= es to the Cluster with no processor name or assigned >>> architecture ? >>>>>> -> If we have an "yes" for the question above: >>>>>> -- We will have to assign the architecture to the Cl= uster based on the OS of the first assigned VM, and the processor name >>> could be defined the same way as currently ... editing the Cluster or a= ssigning a compatible Host to it. >>>>>> -- The VM creation popup will have t= o be able to indicate the architecture of each OS ... some OSes have the sa= me >>> name, and it may get ambiguous since the Cluster architecture is still = undefined at that point (before the first VM get already created). >>>>>> >>>>>> Thanks! >>>>>> Regards. >>>>>> Leonardo Bianconi >>>>>> >>>>> To add VMs you anyway need a running host in the cluster which means = the cpu name and the architecture would be the host's. >>>>> So we can keep the cluster attributes - "cpu name" and "arch" consist= ent and allow them to be empty on creation. >>>>> >>>>> >>>> Hi Roy! >>>> >>>> There is a way to add VMs in a cluster with no hosts running. Steps to= reproduce: >>>> - Initialize the oVirt engine with a new data base >>>> - Create a new Cluster (I will call it of newCluster) in the Data >>>> Center Default >>>> - Add a host in the newCluster >>>> - Add a Storage >>>> - Create a VM in the Cluster Default >>>> Result: The system allows a VM in a cluster with no Hosts running in i= t. >>>> >>>> Is it a bug or a system functionality? If it's a functionality, the is= sue above can happen. >>> Just to clear this one - its a functional thing. its a bit confusing bu= t not too complicated: >>> >>> Storage and all its related actions/entities are related to the Data Ce= nter (aka, code-wise storage pool). Its possible to create a VM >>> once the DC is up, without a cluster i.e also provision disks to it and= so on. >>> >>> Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, n= etwork config etc, must be homogeneous in order for VMs to >>> migrate between hosts which means we must have a running cluster i.e at= least 1 running host in it. >>> >> Roy, thank you for the explanation! It`s clear now >>> >>>> >>>> Thanks!! >>>> Regards. >>>> Leonardo Bianconi > > Hi Itamar, sorry about the late replay. > >> Leonardo - slightly related - is this ppc big endian, small endian? any >> thoughts on current and future plans around endianes? > > PPC64 is big endian, but they are working to enable little endian. > >> also, can you help with my, well, ignorance - are ppc7+/ppc8[1] a newer >> cpu level, also not backward compatible, etc.? > > Yes, Power7 and Power8 are different on family of processors. On the oVir= t wiki, pinatti, from IBM, wrote that the CPUs wouldn't be compatible with = each other, so I asked him about the backward compatibility and he answered= they don't know what will be the compatibility level between Power7 and Po= wer8. > > More information about Power8 can be found here in http://www.pcworld.com= /article/2047733/ibms-power8-opens-up-to-component-makers.html > >> Thanks, >> Itamar >> [1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html >> (courtesy of rich jones) ok, i guess we'll handle little endian and power8 when they become = relevant... --===============8348470004514413820==--