On Mar 18, 2011, at 9:46 PM, Ian Main wrote:
On Thu, Mar 17, 2011 at 11:04:28AM -0700, David Lutterkort wrote:
On Thu, 2011-03-17 at 09:05 +0100, Michal Fojtik wrote:
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:
Will held configuration file used by DHCP server to assign IP from MAC address
Will do a POST service for in-guest-agent inside Condor VMs
That can be achieved by adding one more POST handler to the Deltacloud application.
Will Falcon then support both modes of operation, explicit IP assignment controlled by a Falcon-supplied DHCP server, and scraping IP's out of running instances via an agent ?
Yes. The other thing is authentication. Basically there will be configuration required on the condor-cloud side that I'm not sure belongs in a driver.
What sort of authentication you mean? I can use LDAP/Kerberos auth for Condor.
You are correct that this could be done with a gem or even just a script (almost) but to have a running process will be useful for eg the dhcpd case etc. I was a bit torn on this too and decided I would run with the REST api. In the end both will work.
Yes, after brief talk with David I agree to create a gem instead of writing a new REST API. Even code I wrote in Sinatra perfectly replicate DC API structure, so this redudancy is not needed.
I removed Sinatra application today and finished with 'launch_instance' and hardware profiles.
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...
Is that a real deployment concern ? I would hope that Condor already gives us all the deployment flexibility we'd need, so we can always pretend that condor is running local to the server. Are there actual requirements that make it impossible for us to run the Deltacloud server and Condor on the same machine ?
Condor can do remote calls. Also I don't think it's an issue generally to have the driver on the same machine as there's already the REST api there making it network capable of course. That is not why we went this route.
Agree.
Just as a reminder: the fact that all deltacloud-core drivers talk HTTP out the back is not because it's an elegant design choice - it's by necessity, since the only API's we can talk to are via HTTP. For Falcon, there is absolutely no reason why we'd need to have the same sort of split, and where the other DC drivers use HTTP to talk to the backend cloud, we can use in-process calls to talk to Condor. That's an order of magnitude easier to design and test.
There is a logical split here. I also want to be able to develop the condor-cloud side without having to modify the driver all the time, so some kind of logical separation is required.
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.
There's no need really to have an internal remote API for Falcon at this point. I would assume that that internal API will closely mirror DC anyway, and most of the work that needs to be done in the DC driver will be fairly artificial and redundant. It would mostly amount to deserializing one format and then serializing back into an almost identical format.
As for deployment/scalability flexibility, I would _definitely_ not use a REST based API for that - if needed, AMQP would give us much more flexibility and scalability.
But those concerns are premature: for now, it's way enough to have the Deltacloud driver interact with condor directly, not over a remote API.
OK, to summarize, basically by doing the REST API we can:
- Develop the condor-cloud portion outside of the driver, eg add new IP
snarfing techniques etc. without changing the driver.
IP management could be also done on configuration server side. Deltacloud API driver can connect to this server and retrieve IP informations for instance.
- Have configuration of the condor-cloud portion without it being part
of the driver, it will feel like its own piece of software, which it should be.
- Things to configure include authentication, IP management techniques,
various limits on CPU/memory etc., location of image repository, and specific VM configurations.
- Having an agent, eg daemon type process, lets us accept callbacks
from whatever IP management system we use, watch dhcpd logs or what have you.
The downside being it may be a bit slower, maybe a little harder to develop? Although seeing how it works I don't see it being much harder to develop than any other API. Michal already has the groundwork up and running. Again I don't think it's a make or break thing here..
It was *very* simple Sinatra app, but now it's removed and replaced by gem code. We can still do a Sinatra app build on top of this gem.
I'll see how Michal is making out and if we need to strip this back some for time reasons.
I'm happy with this solution:
deltacloud-client -> deltacloud-condor-driver -> condor-cloud-gem -> Condor
condor-cloud-gem will be interface between Ruby and Condor.
-- Michal
------------------------------------------------------ Michal Fojtik, mfojtik@redhat.com Deltacloud API: http://deltacloud.org