On Mar 17, 2011, at 12:43 AM, David Lutterkort wrote:
On Wed, 2011-03-16 at 20:23 +0100, Michal Fojtik wrote:
Actually we was thinking about using Sinatra app which talks to Condor and translate queries for Deltacloud API to handle this IP managment.
To make sure I get this right: the flow then is
* client -> deltacloud-core server -> new sinatra app -> condor
Yes this is right.
Which raises the same question I asked yesterday about vSphere: why does the interface marked with (*) need to be REST ? Wouldn't it make more sense to collapse all that into the deltacloud-falcon driver so that the interface (*) is just normal in-process calls within the driver ?
This application will do an IP management for Condor cloud, so:
1) Will held configuration file used by DHCP server to assign IP from MAC address 2) Will do a POST service for in-guest-agent inside Condor VMs
Another benefit is that you don't need to install Deltacloud API on the same machine where Condor is installed / or install Condor just for doing calls to remote Condor...
My thoughts are to use this app to 'simulate' 'real' public cloud behavior which obviously expose some sort of API. In this case it will be *very* simple API. Then in DC driver we can just use RestClient + Nokogiri to parse XML.
-- Michal
I am all for abstracting the deltacloud driver/condor interaction a little bit, but that can also be done by putting that code into a separate gem or similar.
David
------------------------------------------------------ Michal Fojtik, mfojtik@redhat.com Deltacloud API: http://deltacloud.org