Mixing AMIs?

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Sat Apr 16 01:41:20 UTC 2011

> Interesting. I'm fairly certain there will be ensemble power users who
> will build their own AMI or LXC container with a special kernel and things
> that can't be done via apt-get. That is why I selected the term 'image'.

We'll definitely want to support these use cases too, but there's a
distinction between the convention we'll be using for all of the
standard formulas and most people will rely on, and the features
for power users that want to use the system in advanced ways.  Building
a suitable system for the latter is relatively easy (lovely apt pinning!),
but building a system for the former is where our energy is focused
since it will determine the real value of Ensemble.

> Its more about suggesting the best one for that formula. For instance,
> A PHP app server has almost no reason to run in 64-bits. It would be
> almost crazy to have PHP consume more than 2G of memory in a single
> process, meanwhile the doubled pointer size will just be wasting RAM in
> 64-bit mode. Thats a bit of sysadmin knowledge that is great to codify
> in a formula so that other sysadmins don't have to learn this trick the
> hard way.

Sounds good, we can implement something like this at the formula level
too, but there are a few gotchas.  If someone deploys 5 services in
two machines, we'll have to make a decision regarding the formula's
preference.  Then, we'll have to make a distinction between the formulas
that use the architecture hint as an advice, and the ones that *depend*
on the architecture (binary object only available on architecture X).

That's why I think stacks are a better home for the case where the
architecture is merely an advice.  They are the place where a clever
sysadmin can tweak knobs to come up with a full deployment which
is really suitable for that one case he's thinking of.  Building on the
example, 64 bits isn't just about RAM, but about the addressable
space.  It's not hard to imagine a PHP process mmapping a 2GB
database file.

Gustavo Niemeyer

More information about the Ensemble mailing list