resource maps

[Gustavo Niemeyer]

On Tue, May 8, 2012 at 2:53 PM, William Reade
<william.reade at canonical.com> wrote:
> Following on from the UDS discussion on Monday morning [0], I footnote
> an example of how I might expect a resource map to look for us-east-1 on
> AWS [1].
>
> It's very clearly AWS-focused, but I'm not sure that it's *necessarily*
> AWS-*specific* -- that is, I don't think that there's anything in there
> that couldn't translate to other cloud providers. If I'm wrong about
> that in particular, please complain loudly [2].

I think you're right, but we should try to word keys more generically
so that when the next provider comes about with the same concept we
don't have to change the format and the code to handle it. For
example:

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.

> Specific things to notice:
>
> * The images' "hvm" field defaults to "false", and "ebs" defaults to
> "true", but on reflection I think I'd prefer to eschew default values
> entirely and require that all values be explicit.

Agreed. This is assuming too much. I'd prefer something closer to the
above, with dumb handling code-wise.

> * The instance-type fields which need to be cross-referenced with image
> fields (arch, ebs-image, hvm-image) are all lists rather than naked
> values. In the first two cases, this is clearly necessary because Amazon
> itself already allows for variation in those fields per instance-type;
> and in the final case, it seems sensible because I don't believe there's
> anything fundamentally different about HVM to lead it to be classified
> differently (that is, I can readily imagine a cloud provider that
> allowed you to run a particular instance-type either with or without
> HVM).

Given the above scheme, that latter situation would be handled by just
not saying anything in the requires and conflicts statements.

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

> * instance-store defaults to 0, but t1.micro is the only instance type
> that doesn't have instance storage, so that's not immediately obvious.

Same thing. We're not handling instance storage in any useful manner
for the moment. I'd prefer to have that information out while we don't
figure how we want to handle it in more detail, and then once we have
a use case at hand we can easily introduce the data in the proper way
that is sensible for the use case.

> * As discussed, Juju would expect a "resource-uri" environment setting

Something like "provider-resources" might be slightly more
descriptive, yet still generic enough for that file to be enriched
with further details about the provider.

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

> * I'm not sure that libcloud is going to be as helpful as we'd hoped. It

Indeed, libcloud isn't a good fit for this use case.

> I hope this helps to crystallise the discussion a little bit...

It does, thanks!


gustavo @ http://niemeyer.net