constraints - observations and questions (bringing to list)

[Tim Penhey]

On 13/02/13 12:59, Gustavo Niemeyer wrote:
> Hey Tim,
> 
>> 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.

Fair call, but this doesn't necessarily take it off the table.

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?

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

I agree that it isn't necessarily the place to start, but what I wanted
to illustrate was that the concept isn't broken, just hard.

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

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.

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

The problem with that is that "cpu" has a different meaning, and
overloading the semantics of that is just confusing.  Choosing something
more arbitrary and generic, like "power" (or something else that isn't
too overloaded with meaning) would be preferable.

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

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

Tim