constraints call notes/proposals/sync

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Fri Feb 8 17:58:28 UTC 2013


On Fri, Feb 8, 2013 at 3:43 PM, William Reade
<william.reade at canonical.com> wrote:
> My understanding is that we've already embraced this limitation in the
> large, by agreeing that constraints incomprehensible to a given provider

I haven't, and I wouldn't embrace it. Saying "ec2-type" is ignored is
completely different from instance-type, because the latter can in
fact work to constrain workloads in entirely unintended ways. Not only
that, but it makes it hard for people to produce portable scripts when
they do want to (I want n1.standard on Google, but large on Amazon).

> So, I *think* that the heart of our disagreement is how *much* ambiguity
> we're willing to tolerate, in the knowledge that with ambiguity comes
> surprising behaviour. Would you agree that this is a fair
> characterisation of the problem?

I don't agree with that, for the reasons stated above. It's not just
ambiguity, it's plain incorrectness.

> My contention is that the value my proposal delivers in a large number
> of use cases is enough to outweigh the drawbacks that become apparent in
> a relatively limited range of situations. This is admittedly subjective;
> I'd be keen to hear a range of opinions on the subject.

Indeed, feels very subjective. There are real shortcomings which we
can solve because we are reimplementing the feature again, and it's
*easy* to solve. I would solve them.

That said, I think we understand each others' point of view now, so
I'll let you take full ownership of the new role and decide what's
best for the project.


gustavo @ http://niemeyer.net



More information about the Juju-dev mailing list