Mixing AMIs?

[Gustavo Niemeyer]

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

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

> Would all be allowed, and should be consumable by the machine
> providers. This way a machine provider can just reject a formula/service
> where it doesn't know how to handle things in the ami space, and it can
> figure out what natty-i386 means fairly easily by looking it up as if
> it is each one of the space types it has and then failing only if it
> is ambiguous.

Right.

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

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter