On 05/12/2011 07:53 AM, Angus Thomas wrote:
Thanks for this, Greg. You're right about the bits of the plan which seem to rely on a bit of magic, at this stage.
(phew, I'm not crazy!)
On your first point, there's no simple way to guarantee that the necessary packages are in a template to support late-bound services if users don't refer to the packagegroup that defines those dependencies when they're creating the template, though we can point out when users are adding services to an instance of a template which wasn't explicity deisgned to accommodate that specific service.
Oh, I should quickly point out here that instead of "templates", we're probably talking about "icicle" (as long as it's still called that). IOW, the thing that is produced by Image Factory when it bakes an image based on a template.
This gives us a thing that actually lists all the packages installed in the image. Which gets us closer to being able to detect whether a particular deployable (with late-bound services) is going to violate the pre-defined list of packages in an image.
In mitigation, though, its a problem which, if it occurred, would be immediately apparent on the first attempt to prototype the combination of a template and service and would be easily resolvable.
On your second point, late binding does require a puppet master, or something very like it, to host and deploy the puppet scripts. I think that's the heart of the matter. If we can accommodate that requirement then late binding is feasible. If we can't then we'll be baking the configuration scripts into images.
The questions I have regarding the puppet master are:
1) Where is the puppet master hosted? This is not hugely important, but I want to see if we're thinking about the n+1 (or n+m) problem of instance proliferation needed to support post-boot configuration. If the puppet master is part of the config server, then we're back to n+1. If it needs to be separate (for some reason I don't see right now) then we're to n+2. We have to watch that "+m" piece carefully.
2) Is the user responsible for creating this ahead of time manually? Or, is this something that could be part of the global setup of cloud engine? Probably short term the answer is, "this is manual". Perhaps longer term this could be something automagically configured when a provider is added to Cloud Engine.
3) What about supporting other configuration engines? Does this put us in the business of being configuration engine configurers? Maybe it does, and maybe that's not so bad. Just a big job that changes with each release of the supported configuration engines.
4) JRD's favorite question on this topic: what about someone that wants to manage configurations with bash scripts? Are we precluding this? Does it matter?
There are a couple of points about the pros and cons that I intended to put in my original mail:
Writing the puppet scripts into the template, and into the image, would mean that trivial changes required new images to be built, for each provider. That would make iterative testing very costly, and would lead to a proliferation of near-identical images which, for some providers, the user is paying to store.
Ooh...yeah, this is a very important point, for sure. Getting the services working correctly for any situation is always a very iterative process.
Anything that we can do to cut down the turnaround time on this is a plus.
The need to store a different image for each variation of the services that might run on a single OS, and to do that for multiple providers, will turn into a constraint on scalability once we have users seeking to manage hundreds, or thousands, of instances.
This is where I get hung up.
I see that there's two competing issues here. One one hand, we want to provide the user with a way to spin up an instance an be running quickly. This requires that the image be pre-loaded with all (or almost all) the packages required to be running for instances based on that image.
On the other hand, we want to provide the user with flexibility of being able to customize the instance with post-boot configuration so that they might spin up several instances from one image and have those instances be fairly distinct from each other (e.g., db server and http server from one image).
It sounds like the solution being talked about is to front-load all the packages into an image so that it might be able to satisfy both requirements simultaneously. That might be a good solution for the interim, but I think the image proliferation problem is going to get real really fast despite this solution.
The big piece I don't have a good grasp on is which requirement is more important. Image proliferation looks like it costs money (thinking of EC2), since the user has to store all those images, probably in an S3 bucket, right? Whereas spin up time is operational cost to an IT center (i.e., the site is down, disaster recovery must kick in NOW). I guess the real answer is that this particular balance of requirements is going to change with each customer. And, we need to be able to support both models.
Late binding of services would allow users to get flexibility out of a smaller number of images, by separating the OS, which shouldn't need to change frequently, from the services, which are likely to change more rapidly.
Angus.