-----Original Message----- From: Itamar Heim [mailto:iheim@redhat.com] Sent: terça-feira, 30 de julho de 2013 16:30 To: Leonardo Bianconi Cc: Vitor de Lima Subject: Re: [Engine-patches] Change in ovirt-host-deploy[master]: packaging: Fixed building RPMs on non-x86_64 architectures On 07/30/2013 10:26 PM, Leonardo Bianconi wrote: > Hi Itamar! > > I'm working on the API change: > >>> I think setting it from cpu name automatically and having it read >>> only makes sense API wise. >>> GUI wise, i'm torn, but you could always make the API only accept >>> the cpu, and let the user use the arch only to filter the cpu models, etc. > > I looked for how create a field read-only, but I didn't find anything in the wiki. So, I added the field 'Architecture' for cluster, getting it from the CPU object. In the file rsdl_metadata.yaml I added the architecture field as optional for the cluster's requests (update and add) and internally it is being defined by the CPU name, so when the architecture is sent in the xml, it is ignored. I tested it and it`s working fine. > > Is this the read only behavior you expect for the API? can you please re-send with engine-devel in cc so i can cc the rest api maintainer easily? thanks > > Regards. > Leonardo Bianconi > >> -----Original Message----- >> From: Vitor de Lima >> Sent: terça-feira, 30 de julho de 2013 11:11 >> To: Leonardo Bianconi >> Subject: FW: [Engine-patches] Change in ovirt-host-deploy[master]: >> packaging: Fixed building RPMs on non-x86_64 architectures >> >> >> >>> -----Original Message----- >>> From: Itamar Heim [mailto:iheim@redhat.com] >>> Sent: segunda-feira, 29 de julho de 2013 09:59 >>> To: Vitor de Lima >>> Subject: Re: [Engine-patches] Change in ovirt-host-deploy[master]: packaging: >>> Fixed building RPMs on non-x86_64 architectures >>> >>> On 07/29/2013 03:38 PM, Vitor de Lima wrote: >>>> Thanks, the problem is I had issues testing it on a x86_64 machine. >>> Everything is OK right now and unfortunately I rebased the patches, >>> so the code review must be done again. >>>> >>>> I have a question, the engine patch is in review process, after >>>> adding the >>> architecture field I thought a little bit about how the REST API >>> would be changed, so far I have two options on how to integrate this >>> new field. I could export the architecture field to the user of the >>> API, so the resources would have the architecture field accessible >>> to the user of the API. This can cause problems related to bad user >>> input (like a cluster with a POWER cpu name and an architecture field defined to 'x86_64'). >>>> >>>> On other hand, I could hide this field and set its content >>>> automatically >>> (derived from the cpu name in clusters and from the selected cluster >>> on VMs, Templates and Pools). Which approach would be the most appropriate? >>> >>> I think setting it from cpu name automatically and having it read >>> only makes sense API wise. >>> GUI wise, i'm torn, but you could always make the API only accept >>> the cpu, and let the user use the arch only to filter the cpu models, etc. >>> >>>> >>>>> -----Original Message----- >>>>> From: Itamar Heim [mailto:iheim@redhat.com] >>>>> Sent: sexta-feira, 26 de julho de 2013 00:08 >>>>> To: Vitor de Lima >>>>> Subject: Re: [Engine-patches] Change in ovirt-host-deploy[master]: >>> packaging: >>>>> Fixed building RPMs on non-x86_64 architectures >>>>> >>>>> On 07/24/2013 03:13 PM, vitor.lima(a)eldorado.org.br wrote: >>>>>> Vitor de Lima has uploaded a new change for review. >>>>>> >>>>>> Change subject: packaging: Fixed building RPMs on non-x86_64 >>>>>> architectures ...................................................................... >>>>>> >>>>>> packaging: Fixed building RPMs on non-x86_64 architectures >>>>>> >>>>>> The DMI decode is available only on the x86_64 architecture, the >>>>>> spec file was changed to reflect this. >>>>>> >>>>>> Change-Id: I691544be6630ed2e88acbf8f1828b7995f582ffa >>>>>> Signed-off-by: Vitor de Lima <vitor.lima(a)eldorado.org.br&gt; >>>>>> --- >>>>>> M ovirt-host-deploy.spec.in >>>>>> 1 file changed, 2 insertions(+), 0 deletions(-) >>>>> >>>>> >>>>> hi vitor, >>>>> >>>>> just to make sure the status is clear - alon mentioned on both >>>>> these >>> patches >>>>> to "please verify". this means he expects you to tick the 'verified' >>>>> checkbox >>> on >>>>> the gerrit patch and commenting that you tested this works for >>>>> you, >>> doesn't >>>>> break things, etc. >>>>> once you do that, he can merge the patches (he already approved >>>>> them) >>>>> >>>>> Thanks, >>>>> Itamar >