resource maps

[William Reade]

On Mon, 2012-05-14 at 11:19 -0300, Gustavo Niemeyer wrote:
> images:
>     ami-n:
>         provides: ebs hvm
> instances:
>     inst-m:
>         requires: ebs
>         conflicts: hvm
> 
> The matching logic may be done by juju without any knowledge of what
> "ebs" and "hvm" actually mean, I believe.

This sounds nice.

> > * The "cost" field happens to mean dollars-per-hour -- as published by
> > Amazon, excluding considerations of EBS storage cost, etc -- but doesn't
> > *necessarily* have that meaning: on a private cloud, for example, it may
> > be very difficult to come up with precise costs, but one will still want
> 
> Indeed. I'd prefer to keep that information out of the file, for the
> moment. We can go a long way onto agreed territory before having to
> settle out on the use and semantics for that.

Hmm, I feel we need to provide some way to rank instance types along
this axis (a cc2.8xlarge does fulfil the default constraints, but should
probably not be used when someone's experimenting with
wordpress/mysql...). 

It seems to me that the simplest option is to expose "cost", treat empty
costs as 0, and choose arbitrarily between equally-cheap options; it
solves the problem we have now, and doesn't tempt us to define an ad-hoc
weighted feature-cost-ranking algorithm which would IMO become a
millstone (or irritate users when we inevitably tweak it).

> > to point to something like this; in EC2, and potentially other public
> > clouds, you'd leave it blank to get the standard data (that would be)
> > published by Canonical, but you'd provide your own data for private
> > clouds.
> 
> +1. As we discussed, some of the backends may also adopt a hybrid
> approach, where the "static" resource file (it doesn't actually have
> to be static) might be enriched with information that is dynamically
> obtained by the backend itself while talking to the provider (typical
> case: openstack can tell us about at least some of the details of
> available images).

Yep; this would be cool. Unless you suspect the current proposal closes
any doors on this, I'd prefer not to focus on this for now.

Cheers
William