On Tue, 2011-03-15 at 13:35 -0400, Ian Main wrote:
On Tue, Mar 15, 2011 at 11:17:32AM -0400, John R. Dunning wrote:
- Assuming I'm correct about 4, that server can also communicate the
IP address of the booting instance back to the mother ship (conductor). So there's no need to build any other scheme for managing IP addresses.
So I may be wrong about this, but what I think I'm seeing here is that the config server is NOT the same piece of software as the agent we are making, and it is the agent which should know the IP. Generally the flow of information is from deltacloud/condor to conductor, you are talking about going around deltacloud here and injecting data directly into conductor.
I guess I don't understand enough what is meant by the config server here, and who controls it. For just a basic cloud, I would keep this piece as simple as possible - whether people want to have instances talk to a puppet server, cfengine or whatnot shouldn't be part of this cloud.
If we are really convinced that the only way we can get IP information is by instrumenting images (I am not), we should keep this callback to just that.
In that case, since the instance/IP map resulting from the callbacks is internal to the cloud, there's no layer violation; the Deltacloud driver will just consult the IP map when generating details about an instance.
That said I guess there's no reason we couldn't do the registration twice. Basically ec2 supports reporting its public IPs and I would like to do that in this condor cloud as well. The config server thing and reporting IPs directly to conductor is, as far as I understand, a separate issue.
Absolutely agreed.
- We will need to work out the admin details of standing up the
stateful server piece, presumably including the condor instance, the config server, and the interface piece. I believe David has volunteered to take a look at this piece.
I was not aware of that.
Neither was I ;) Suffice it to say that you are not duplicating existing work.
Do we need to do anything about mac address management? Is that part of 1?
That will be up to the 'agent' that is between the deltacloud driver and condor.
We have two options: (1) generate random MAC's whenever we start a VM or (2) assign a known MAC when we start a VM. I'd be surprised if (1) would fly in many environments. As such, there needs to be a way to configure a MAC address range from which we pick.
David