constraints - observations and questions (bringing to list)

[Gustavo Niemeyer]

Hey Tim,

On Tue, Feb 12, 2013 at 8:40 PM, Tim Penhey <tim.penhey at canonical.com> wrote:
> After some more reading, and poking about it seems that cpu isn't cpu at
> all, but instead refers to the ECU (EC2 Compute Units).

ECU is actually a unit of cpu power. The original idea was to take a
well known measure and run with it in the other providers. It was
half-sensible, at least, given that Google agreed and went with a very
similar measure. For some reason it didn't fly in the other providers,
but I still think it's easily doable (we can do a hardcoded "N cores *
X" kind of function, when we don't know better).

> It is my current understanding that right now we instantiate a machine
> for each service + 1 for the agent.  If I'm at the state where I want

I'll skip that question as it is off topic. I'm happy to talk in a
different context, though (another thread, for example).

> Do we allow the user to specify environment constraints in the
> environments.yaml file?  Instead of necessarily setting the constraints
(...)
> Having the ability to have the deployment constraints in a file gives
> you a simpler way to manage the defaults constraints for particular
> services.

If we allow them in the file, it's necessarily only for bootstrapping,
and doesn't handle the case you describe above. The environment holds
the authoritative information for the environment itself. If multiple
administrators are using that environment from multiple clients, they
must all see the same configuration.

(...)
> names?)  Can we, with some rationality, convert the named instance types
> for the particular providers into some set of known meaningful constraints?

Yes, and I still find that idea attractive. That said, it ought to be
properly specified before we start anything like that, as there are
quite a few things to get wrong. Specifications change, and are
dynamically available for some providers, or even not-available at all
for others, the described issue regarding how generic "instance-type"
is and how it is a global vocabulary still exists, and so on.

For those reasons, if anything, this doesn't feel like the place for
starting. We can do something much simpler to begin with, and get
going. We just have to be aware of those issues to make sure we're not
going down a path of difficult resolution later.

(...)
> crackful. I think that we should have some measure of computational
> power (like ECU) that we can then have different instance machines from
> different providers provide a calculated (albeit roughly) value that
> juju then uses in deployment instructions.

We're in total agreement, and that's already what "cpu" is meant to be.

(...)
> This is exactly what I just mentioned above, and that we have both come
> to it independently makes it more likely a useful measure.  Especially
> if there is a public, simply found, translation mechanism that we use to
> say:

Amazon already defined such a system, and Google borrowed it. Seems
like a good place to start.

(...)
> I'd also expect the provider to be able to tell me if I ask for an
> instance type that doesn't exist.  Is this possible?  Are we hard-coding
> values, or do we have a way somewhere to get the underlying provider to
> tell us what their instance types are?

Those are all good questions to keep in mind when putting the API in place.


gustavo @ http://niemeyer.net