constraints

[roger peppe]

On 6 February 2013 22:58, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> On Wed, Feb 6, 2013 at 8:31 PM, roger peppe <rogpeppe at gmail.com> wrote:
>> That seems problematic to me. ec2-type isn't a scalar value,
>> so it's difficult to say what "max" means here.
>
> The provider necessarily must know how to map from mem to an ec2-type,
> so max seems straightforward to compute.

I'm probably being stupid here, but it doesn't seem *that* straightforward
to me. If we can express an instance type as a set of non-provider-specific
constraints then it's ok - something like the following algorithm
would suffice:

http://play.golang.org/p/uC7Jkwstry

Then we'd combine constraints by taking the canonicalized
form of each set of constraints and taking the maximum
on an attribute-by-attribute base, then map back into
an instance type.

The problem with this is that the original specification is
lost - the resulting set of constraints no longer includes the
fact that we'd specified "m1.small", but only the set
of portable constraints that that implied.

That's fine if the provider-specific constraints correspond
well with portable constraints, but I'm concerned that
in general I'm not sure we *can* express arbitrary
provider-specific attributes in portable form.

William's approach (instance type overrides other
attributes) is simpler and quite attractive, but has
the issue that instance-type is "infectious" - if you
specify an instance type at environment level,
all attributes in service constraints *other* than instance type
will be ignored. Thus you'd be forced to use non-portable
instance types rather than the more appropriate memory
and cpu attributes. If there were more provider-specific
attributes than just instance-type, the problem could
become worse still.

Perhaps we should move forward entirely without
provider-specific attributes until we can decide on
a decent solution to this.

> People can do "mem=" to reset a setting.

That means that people need to know which other constraints
are implied by any particular provider-specific attribute,
so that they can override them. That's something which may not
even be constant for a provider - for example if an instance
type maps to an arbitrary group of instances.

  cheers,
    rog.