constraints

[roger peppe]

On 6 February 2013 21:32, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> On Wed, Feb 6, 2013 at 7:23 PM, roger peppe <rogpeppe at gmail.com> wrote:
>>> 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.
>
> If we support provided-specific instance types, we should support
> having a command that works no matter what's the provider. Saying "you
> should know what the provider is, so that you can change the command
> line accordingly" isn't ideal, IMO.
>
>> Are you suggesting that all constraint attributes with the
>> prefix "ec2-" are treated specially, or just "ec2-type" itself?
>
> The latter.
>
>> How would mixing constraints work (for instance, does the
>> ec2-specific attribute always cause all other attributes to be
>> ignored?)
>
> I don't understand the question. It's handed off to the provider for
> handling just like any other constraint.

If that's true, we still need to specify how the provider should
handle this kind of constraint. For example, what should happen
when the user does this?

juju bootstrap --constraints 'ec2-type=m1.small'
juju deploy --constraints 'mem=4G' mysql

I'd like to see a model that's predictable for users here,
rather than leaving everything down to each provider-specific
constraints implementation.