constraints

[roger peppe]

On 7 February 2013 20:14, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> On Thu, Feb 7, 2013 at 9:04 AM, roger peppe <rogpeppe at gmail.com> wrote:
>> 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
>
> I'm the one lost. Where is the difficulty in knowing that m1.small has
> X amount of memory and comparing that to the Y which was provided to
> mem?

There's no difficulty if m1.small is treated exactly as if it's
the constraint vector {cpu=1 mem=1.7G}. I'm ok if we want to do
that, but I fear that people might want a provider-specific
attribute to imply more than just a cpu and memory
constraint.

To rephrase, there's a conflict between saying "I want an m1.small"
(I know what I'm asking for) and "I want at *least* an m1.small"
(I know that m1.small implies certain performance attributes
and I don't care if I get something at least as good).

For ec2 instance types, the latter interpretation seems fine, but
if on some provider we can provide a tag which specifies
an arbitrary group of machines, I think it might lead to
unintuitive behaviour.

I suppose for tag groups, we could scan the machines,
find the minimum performance attributes of all of them,
and use that as the constraint, but there may be other
implicit attributes we're not aware of (maybe this tag specifies
all the machines on a given intranet, for example)

>> That means that people need to know which other constraints
>> are implied by any particular provider-specific attribute,
>
> They certainly must know what other constraints exist to know what is
> going to be selected. It's no different from providing a cpu=1 when
> mem=16GB is in the default settings.

See above.