On Fri, Mar 18, 2011 at 02:34:48PM -0700, David Lutterkort wrote:
On Fri, 2011-03-18 at 16:46 -0400, 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.
For purposes of Falcon, let's just forget about drivers as we know them
- they are really an artifact of the way Deltacloud has to work when it
is adapting existing public cloud API's.
What the Falcon frontend should be is a Deltacloud server, modified such that it maintains state, handles auth etc. In terms of how the code is structured, that will look a lot like an existing driver, but the Falcon 'driver' will be a full-fledged webapp.
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.
How so ? We can easily add handlers in deltacloud-falcon that deltacloud-core does not have, e.g. http://localhost:3001/let-me-give-you-my-ip
Really it would be best for the IP information to end up in the condor job, but that's a side point. In order to facilitate some of the IP schemes you would need a long-running stateful process is all I'm saying.
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.
I agree that there is a logical split _somewhere_ - though in terms of dev and getting stuff done, a fairly monolithic code base will definitely be faster than a separate gem, or even a seperate web service.
Well I hadn't considered that as an option. I didn't think a fork of deltacloud would be viable. I should chat with you about this idea.
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.
- 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.
All of this can also be achieved with a 'driver'. In terms of decoupling Falcon and Deltacloud development, you can just work off a clone of deltacloud-core somewhere.
Yes they can I just thought you wouldn't want those things in a driver. Again I hadn't considered the standalone-deltacloud case. I like that idea even more than the gem though.. I don't really want to carry a gem. I'll chat you up about this soon.
Ian