constraints - observations and questions (bringing to list)

[William Reade]

On Wed, 2013-02-13 at 15:45 +1300, Tim Penhey wrote:
> I would think that if you had multiple people collaborating on using the
> same configuration file, that they'd use some form of revision control
> system underneath.  Which brings me to another question, do we have the
> ability to specify something like JUJU_CONFIG_DIR which defaults to
> $HOME/.juju for this type of example?

In theory, environments.yaml is only useful for bootstrap and
destroy-environment. In practice, it's still used to figure out how to
connect to a running environment, but this should be considered a wart,
and we shouldn't be writing code to support the model described above.

That's not to say that a JUJU_CONFIG_DIR that points to that directory
is a bad idea -- I imagine it'll be where we keep conn details for known
environments -- but there's little immediate call for it.

> If we want to give starting parameters, I'd suggesting going with:
>  * mem
>  * power (or equivalent JCU - juju computational units :-)
>  * architecture

Architecture's a little bit interesting, as described in the other
thread; I think it's another instance of the invalid-vs-unsatisfiable
question. If we include it (and I don't see how we can't) I think we
force our own hands wrt instance-type, unless we resign ourselves to
inconsistency across the two constraints.

I'm also still not quite sure why people are dismissing "cores", when
it's demonstrably a more valuable measure than ECU (otherwise I believe
python maas/openstack would have used "cpu" to mean "cpu" instead of
"cores"). Would someone try restating the objections? I might still come
to understand...

> I don't think anyone is arguing about these (except perhaps how we
> represent power).
> 
> Then as we define a better provider API, look at:
>  * instance-type
>  * zone
>  * other-yet-to-be-determined-configs
> 
> 
> It is much easier to extend something working than to try to get
> everything right up front.

So far we seem to have agreed that "mem" is probably OK as it is, but
discussion of every other constraint continues unabated (except for
those we haven't started on yet...).

> > (...)
> >> 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.
> 
> How many people do we need to get to agree to make this concrete?

If nobody disagrees, I'm inclined to go with "cpu-power" ("power" isn't
exactly unambiguous or unimportant either...), and define it as measured
in ECUs. I agree it's a useful-enough measure, even if it's a bad fit
for openstack -- not every constraint has to be implemented everywhere.

This does make me think that maybe, for consistency's sake, we should be
using "cpu-cores" and "cpu-arch". Opinions?

> > (...)
> >> 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.
> 
> Oh?  We don't have an existing way of talking to the providers?

We can talk to the providers, but not in these terms. Our application of
the YAGNI maxim has been pretty ruthless.

Cheers
William