Ok, no problem. Thanks
-----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]:
Fixed building RPMs on non-x86_64 architectures
On 07/24/2013 03:13 PM, vitor.lima@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@eldorado.org.br> > --- > 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
packaging: 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