On 21/12/12 14:50, Oved Ourfalli wrote: > Hey, > > I saw that I sent the patch before adding the requirement in a newer rbovirt > version, so I've attached the updated one. > Sorry about that.
k no worries - as we discussed on irc, I already pushed the previous patch. So i'll just have to make a new patch now for the gemspec update and will push it separately, marios > > Thank you for your help, > Oved > > ----- Original Message ----- >> From: "Oved Ourfalli" <[email protected]> >> To: "[email protected]" <[email protected]> >> Cc: [email protected] >> Sent: Friday, December 21, 2012 2:37:41 PM >> Subject: Re: Fwd: Patch to support User-Level API >> >> Thank you. See my answers inline. >> >> ----- [email protected] <[email protected]> wrote: >>> On 20/12/12 18:22, Oved Ourfalli wrote: >>>> Hey, >>>> >>>> This patch supports the User-Level API in oVirt. >>>> Note that I wrote some issues below. I opened tickets on them, >>>> and I think most were fixed, so just have a look at the patch >>>> when you can. >>>> >>>> Thank you, and happy new year everyone! >>>> Oved >>>> >>> >>> ACK && PSH. OK, to make sure I understand the situation: >>> >>> * even with this patch, the 'default' behaviour if as a user you >>> don't >>> know anything about 'user-level' API is to use the 'admin' API - >>> i.e. >>> like before. >>> >> Default is admin api, unless api_provider ends with USER. >> >>> * this patch allows you to specify that the created client which >>> talks >>> to rhev will query on the user-level API. >> Yes >>> >>> * beyond initialisation of client, changes will be required in the >>> various driver methods to make use of the user-level API >>> functionality >>> (not in this patch/not done yet), >>> >> They won't be needed, as operations are supported in both admin and >> user api. If we find gaps/bugs we will need to address them, but >> basic actions work properly. >>> * there are some problems/issues with the UL api - i) supported on >>> particular versions of rhev/ovirt (like > 3.x?), ii) we need an >>> update >>> to the rbovirt gem in order to make use of it, and iii) create VM >>> is >>> broken to ul api (as you noted). >>> Based on these, I personally don't see the utility of having this >>> flag >>> available until at least ii and iii are addressed. However, since >>> we >>> don't document this functionality (yet, and we definitely need to >>> but >>> only when it's all working and ready) I think its safe to push this >>> for >>> now as you told me you'd like to have in the next dcloud release, >>> in >>> order to continue working on this functionality. >>> >>> >> In the patch I required a more updated version of rbovirt, that have >> this support. I'll recheck that just to make sure. In latest ovirt >> source it works properly (also in 3.1.0.3 version), so only older >> versions that will chose to work with it may fail. >> Thank you! >> Oved >>> marios >>> >>> >>>> ----- Forwarded Message ----- >>>> From: "Oved Ourfalli" <[email protected]> >>>> To: "[email protected]" <[email protected]>, "Michal Fojtik" >>>> <[email protected]> >>>> Sent: Monday, December 10, 2012 10:55:09 AM >>>> Subject: Patch to support User-Level API >>>> >>>> Hey, >>>> >>>> I've attached a patch that uses the API_PROVIDER to configure >>>> whether we work in Admin or User-level API. >>>> Marios - I know you didn't like that approach so much, but as >>>> Michal mentioned in the meeting we had, it will allow setting it >>>> also using the HTTP header X-Deltacloud-Provider. >>>> >>>> Also, in order for it to work we need a new rbovirt version (and >>>> also add a dependency on it to this patch). >>>> >>>> Is that okay with you? >>>> Michal - if so, can you release rbovirt with the latest changes? >>>> >>>> I tested EC2 and CIMI (using examples from my blog :-) ) and only >>>> some basic deltacloud API tests (as I'm less familiar with it). >>>> >>>> I saw the following issues: >>>> 1. CIMI - create VM is broken to user-level API - need to >>>> getCluster by ID and we don't support that. >>>> The result is failing to create VM without specifying target >>>> cluster. There is no way to tell CIMI which cluster you want >>>> your VM on... it works well on EC2. >>>> >>>> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=876460 >>>> Patch by Ravi: http://gerrit.ovirt.org/#/c/9248/5 >>>> Maybe we should consider fixing this bug also on z-stream? >>>> >>>> 2. Delete VM in CIMI failed (but it also failed for admin, and >>>> doesn't seem related to the ovirt driver). >>>> >>>> Trace: >>>> >>>> ERROR -- 500: [NoMethodError] undefined method `destroy' for >>>> nil:NilClass >>>> >>>> /autohome/oourfali/git/deltacloud/server/pkg/deltacloud-core-1.0.5/lib/db.rb:51:in >>>> `delete_attributes_for' >>>> /autohome/oourfali/git/deltacloud/server/pkg/deltacloud-core-1.0.5/lib/cimi/models/machine.rb:114:in >>>> `delete!' >>>> /autohome/oourfali/git/deltacloud/server/pkg/deltacloud-core-1.0.5/lib/cimi/collections/machines.rb:66:in >>>> `block (3 levels) in <class:Machines>' >>>> /autohome/oourfali/.gem/ruby/1.9.1/gems/sinatra-rabbit-1.1.3/lib/sinatra/rabbit/base.rb:396:in >>>> `instance_eval' >>>> /autohome/oourfali/.gem/ruby/1.9.1/gems/sinatra-rabbit-1.1.3/lib/sinatra/rabbit/base.rb:396:in >>>> `block in control' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:1265:in >>>> `call' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:1265:in >>>> `block in compile!' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:835:in >>>> `[]' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:835:in >>>> `block (3 levels) in route!' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:851:in >>>> `route_eval' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:835:in >>>> `block (2 levels) in route!' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:872:in >>>> `block in process_route' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:870:in >>>> `catch' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:870:in >>>> `process_route' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:834:in >>>> `block in route!' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:833:in >>>> `each' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:833:in >>>> `roubase >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:936:in >>>> `dispatch!' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:769:in >>>> `block in call!' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:921:in >>>> `block in invoke' >>>> /usr/local/share/gems/gems/sinatra-1.3.3/lib/sinatra/base.rb:921:in >>>> `catch' >>>> >>>> 127.0.0.1 - - [09/Dec/2012 15:09:08] "DELETE >>>> /cimi/machines/ec7fbdba-83d7-4835-b304-0fc1aa90b71a HTTP/1.1" >>>> 500 1459 0.0278 >>>> >>>> Are you aware of this issue? >>>> >>>> Thank you, >>>> Oved >>>> >>> >> >>
