constraints

roger peppe rogpeppe at gmail.com
Wed Feb 6 21:23:50 UTC 2013


On 6 February 2013 21:07, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> On Wed, Feb 6, 2013 at 5:29 PM, roger peppe <rogpeppe at gmail.com> wrote:
>> There seems to be a desire to be able to specify constraints both in a
>> portable way (for example by specifying a required amount of RAM), and
>> in a provider-specific way (for example by specifying an instance type).
>>
>> Part of the complexity of getting this to work well comes, I think,
>> from the fact that we're trying to allow both kinds of constraint in
>> the same constraint set.  That means that we can get arbitrary semantic
>> overlap between provider-specific constraints and portable constraints -
>> the constraint attributes are not orthogonal.
>>
>> I *think* that by explicitly separating portable constraints from
>> provider-specific constraints, the implementation can become simpler
> (...)
>> The combination rules are as follows:
>
> That sounds pretty involved, and a bit problematic.
> instance-type=m1.whatever is an EC2 setting. What happens when we want
> to specify instance types for both EC2 and Google Compute?

Presumably that's only an issue if an environment is running
on both those providers at once? otherwise provider-specific
constraints will be unambiguous with respect to the current
environment.

> I suggest something more trivial:
>
> - Introduce an ec2-type constraint
> - Non-EC2 providers ignore it
> - The EC2 provider handles it in whatever way it pleases
> - Allow mixing of constraints. If ec2-type is seen, the EC2 provider
> will respect it, as documented.

Are you suggesting that all constraint attributes with the
prefix "ec2-" are treated specially, or just "ec2-type" itself?

How would mixing constraints work (for instance, does the
ec2-specific attribute always cause all other attributes to be
ignored?)



More information about the Juju-dev mailing list