On Wed, 2011-03-16 at 10:28 -0400, Greg Blomquist wrote:
+++ John R. Dunning [16/03/11 09:01 -0400]:
Oops, I probably misspoke. I thought when you and I talked on the phone, we said that you were going to think about what the components would need to be for the stateful chunk of code, interfacing between DC API and the buzzard^H^H^H^H^H^H^Hcondor backend. If you've already got enough on your plate that's fine.
Perhaps it will make sense for Greg to look at that?
I'll probably need a little more insight into what needs looking into here. I'm currently working on a "config server", but I'm not sure of the overlap with what's being discussed here. The config server I'm working on is specific to Audrey wrt cross-pollinating instance configs for post-boot configurations of deployables.
That is very much needed, but very different from what Falcon needs; it should be possible to stand up a Falcon instance, without using Conductor, Audrey or any of the other higher-level services we are working on. That should give you a private cloud that lets you run your own homegrown images and talk to it via Deltacloud.
There are really two 'config servers' in play here:
1. The server to which an instance posts its IP address; for all intents and purposes this could be the Deltacloud server itself. To make this scheme moderately secure, we should inject 3 pieces of data into an instance: the IP of that server, some sort of UUID for the instance, and a secret token that only the instance and this config server know. The instance then posts its IP, its UUID and hte secret token to update the instance/IP mapping. 2. The post-boot config server that is part of Audrey II - a completely separate animal.
David