constraints call notes/proposals/sync

[William Reade]

On Thu, 2013-02-07 at 12:35 +0400, John Arbash Meinel wrote:
> ...
> 
> > 
> > If, on the other hand, it's an ec2-only constraint, I am concerned
> > that to implement is is implicitly to drop flavor support in
> > openstack, in favour of a provider-specific measure that will make
> > it harder to implement a sane openstack variant (we can't just have
> > os-type, that can vary like anything, and suffers exactly the same
> > problems as any global instance-type measure would).
> > 
> > I presume that there's a third interpretation I haven't spotted?
> 
> I do think this is what he meant. And I think the idea is that while
> you have ec2-type, you might also have openstack-flavor=XXX.
> In which case your driving scripts would do:

Ah, you're right: I had misinterpreted some of the call content; it is
clearly stated in one of the mails in the other thread. Thanks John;
sorry Gustavo. The arguments against a common language (which remained,
AIUI, a competing proposal) stand; if nobody steps up to support them
I'll assume it's off the table. But, in that case, the concerns quoted
above definitely apply.

> juju bootstrap
> -
> --constraints='ec2-type=m1.tiny,google-type=n1.medium,openstack-flavor=m1.notsotiny'
> 
> And then the constraints that don't apply to the provider just get
> ignored (or logged-but-ignored). And you don't have to expose directly
> in the script which cloud it is running on.

But openstack-flavor is inconsistent across clouds in exactly the same
way instance-type would be... so it would be profoundly unhelpful on my
part to bake ec2-specific assumptions and/or constraints into my
implementation and toss it over the wall to you with a cheery "your
problem now!". (I'll probably still do that anyway, unwittingly, in some
way; but I would prefer to avoid wandering knowingly into a situation
that actively makes your job harder.)

Cheers
William