constraints call notes/proposals/sync

[Gustavo Niemeyer]

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.

> 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.

> 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!

> 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.


gustavo @ http://niemeyer.net