Mixing AMIs?

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Fri Apr 15 13:41:53 -0700 2011:
> > I like the idea of cascading defaults.
> >
> > The machine provider has a default machine image (I am avoiding AMI
> > because LXC doesn't know what an AMI is), then the environment has a
> > default image that it prefers. The formula can override that, as can
> > the deploy command.
> 
> You're right, it's not an image, but a release.  Formulas will be
> assigned to releases, and indeed there should be a default in the
> environment.

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'.

> 
> > I think the key would be to allow the optional usage of namespace qualifiers.
> >
> > image: ubuntu,lucid-amd64
> > image: ami,ami-4854f31c2
> > image: natty-i386
> > image: oneiric
> 
> Yeah, we need to think about those other attributes.  Initially, there
> won't be any architecture restriction, but eventually it may be
> important to enable formulas that can only run in a given architecture
> due to external compiled dependencies which are not available in all
> supported architectures as the Ubuntu packages are.

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.

> > Likewise the machine type (t1.micro, m1.large) should cascade in the
> > same manner and just be ignored by providers that have no concept of
> > machine type.
> 
> This feels like slightly different case.  The amount of resources for
> a formula is a generic problem, and may even be independent of the
> previously selected machine (you can have a large machine, and still
> not have memory for a formula).
> 
> We'll have to brainstorm about this at some point to see a proper way
> to address it.
> 

Yeah they are definitely a different problem space. Probably more
important that it can be set at the time of deploy/add-unit than in the
formula itself.