constraints call notes/proposals/sync

[William Reade]

On Fri, 2013-02-08 at 12:32 -0200, Gustavo Niemeyer wrote:
> On Fri, Feb 8, 2013 at 8:29 AM, William Reade
> <william.reade at canonical.com> wrote:
> > It seems that at least one of us is saying things that the other is not
> > effectively apprehending.
> 
> It may well be me, but I promise I'm trying hard at least.
> 
> > If you believe we are in so desperate a situation that it is reasonable
> > to drop or cripple valuable functionality that exists in python, please
> > explain why you believe this to be the case (or drop the "ec2-type"
> > proposal, which appears to be predicated on this belief; nobody has yet
> > come forward to disabuse me of my notion that parity is a fundamental
> > goal).
> 
> Okay, this is one I thought was very clear.
> 
> In my opinion instance-type is a BROKEN CONCEPT. It does not work
> across providers, which is the only reason it was invented as it exists. It
> should be DROPPED and replaced by something less broken.

Thanks; it's very hard for my brain to skew that statement as it has
been doing prior ones on this topic :).

But... I think I'm still unclear about the concept of "works across
providers". Once you take things like cpu/memory overcommitment into
account, *none* of our constraints can actually provide consistent
guarantees across clouds. The local provider doesn't implement any --
not even mem :).

This doesn't mean, though, that the constraints are not useful; nor does
it mean that we should drop every one. What it does mean, I think, is
that we have to design our necessarily-imperfect language with a view to
*minimizing* the incidence and impact of surprising behaviours, rather
than imagining we can eliminate them entirely (and declaring the bulk of
the problem out-of-scope on that basis).

My understanding is that we've already embraced this limitation in the
large, by agreeing that constraints incomprehensible to a given provider
should always be ignored rather than treated as errors. I think my
proposal is philosophically consistent with this policy -- we merely
implement providers such that they're free to ignore invalid values
rather than forced to accept/reject whole constraints.

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?

> > If you believe my criticisms of your "cpu" proposal are not relevant,
> > please explain your reasoning.
> 
> My point was simply that 1 core means very little. But, you're right,
> if people are having a hard time to implement it, just roll with
> something simple. It's easy to reintroduce that later if necessary.

I think it means at least as much as does a measure of rough equivalence
to number-of-2007-era-xeons :). But in the light of the above
ruminations, I don't think I can maintain a strong philosophical
objection to "cpu": our job is really to come up with a minimally
insane/unhelpful conversion factor across clouds.

> > If you believe the "instance-type" proposal, that I presented and
> > subsequently modified in response to roger's feedback, is not the best
> > yet presented -- or is, but remains inadequate -- please expand on this;
> 
> I have not seen any commentary solving the situation that
> instance-type=n1.standard means absolutely nothing across clouds and
> can vary in results to arbitrary degrees. That's not a very useful
> constraint!

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.

> > I've seen an echo of one drawback I had previously pointed out, but
> > nothing addressing my subsequent justification of the proposal as the
> > one that most effectively addresses the needs of our users.
> 
> My most critical suggestion is this: start working on something
> simple, and do not mangle the data. In other words, don't compute a
> magic set of constraints based on some clever algorithm and ignore
> what the user originally provided, but instead store thing store the
> data as the user inputs it (no "computed constraints" in the
> database). You can start with non-polemic settings, such as mem and
> cores. If you do that, you can easily evolve from a trivial algorithm
> to a better one, and not get stuck on this kind of discussion forever.

I have no intention of mangling the data or implementing clever
algorithms (at least, not until it's clear they're required ;p). Any
implementation will necessarily start off small; but if we don't occupy
common ground and agree on a direction now, it will be hard to make
progress with any degree of confidence.

Thank you for your patience :).

Cheers
William