constraints call notes/proposals/sync

[William Reade]

On Thu, 2013-02-07 at 02:36 -0200, Gustavo Niemeyer wrote:
> On Wed, Feb 6, 2013 at 11:56 PM, William Reade
> <william.reade at canonical.com> wrote:
> >   * The "cpu" constraint as it stands is pretty much crack, and might
> >     not even be worth keeping on for ec2. Certainly not useful on any
> >     other cloud.
> 
> We ended up not discussing this in the meeting, and I'd appreciate
> more details if that's okay given that the cpu constraint seemed
> reasonable. Note that Google Compute ended up implementing what they
> call a Google Compute Engine Unit (GCEU) [1], which not by coincidence
> has a good equivalence with Amazon's measure of CPUs.

I think the problems with "cpu" are clearly demonstrated by simply
observing that the implementors of maas and openstack constraints in
python discarded it as worthless, and decided that it should instead
mean "cores". Two out of three is a pretty strong vote.

Are you arguing that "cpu" still has value, and we should keep it
working with ECU on AWS and also implement it for those other providers
that expose something similar? I'm not necessarily opposed to that, but
I'd like to know more about how we do it. Treat every conversion as 1:1
and skip it for clouds that offer "different enough" measures? Maintain
a fictional but convenient mapping between measures? I don't know how to
determine "different enough" fairly, and I fear that this suffers
exactly the same problems I described wrt ec2-type: it's a measure that
forces us to choose between a rigid one-size-fits-all approach that will
tend towards poor but predictable choices, and a fuzzy approach that may
often produce better results but only at the cost of clear and simple
predictability.

> https://developers.google.com/compute/docs/instances#gceu
> 
> >   * A "cores" constraint does make sense on just about every cloud we
> >     know of (and can ofc be ignored, as usual, if it doesn't fit the
> >     current environment).
> 
> I feel exactly the opposite. Saying 1 or 4 cores is pretty meaningless
> if you have no idea of the capacity of such cores.

It's the measure people appear to consider so useful it's worth
sacrificing "cpu" for, in both maas and openstack. I can't speak for
their motivation in detail, but the evidence seems to weigh in favour of
"cores" being a measure that delivers value to our users; and it is also
one that's exposed on even the cloud that motivated "cpu" in the first
place.

If we can iron out precisely what "cpu" should mean across clouds in the
event of differing basic units of compute power, and how we'll
consistently handle providers that instead expose, say, "teraflops", I'm
not fundamentally opposed to it; but I think that an unclear measure is
probably worse than none at all.

> > So, the overwhelming advantage of this approach is that it gives us a
> > common language for instance types (with an option on defining more,
> 
> I couldn't quite spot what "this approach" actually refers to. It mentions an
> "ec2-type" idea right above, but it doesn't seem to be what I understood
> this option to mean at least (it was certainly not a common language
> across clouds).

Honest question, asked in the spirit of discovery: in what way does the
ec2-type proposal differ from my characterization of it? My
understanding from your proposal was that it's intended to be used,
across clouds, to convert an ec2 instance name (the common language)
into common hardware description values that are then matched against
that cloud's available instance-types (where applicable); and I don't
believe the content of the call left me alone in this interpretation.

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?

> >   * instance-type values are not checked at parse time.
> >   * instance-type values no longer conflict with cores/mem, and are
> >     set and inherited independently.
> >   * instance-type values are considered before cores/mem, such that
> >     a specified instance-type that is available in the current cloud is
> >     always chosen regardless of specified cores/mem.
> >   * any unrecognised instance-type constraint is just ignored -- it
> 
> This proposal has the issues I mentioned before: it's problematic to
> have a single setting that is used by all providers with unknown
> vocabularies. How do we specify the instance type of both EC2 and
> Google Compute Engine?  What happens if someone creates an instance
> type named n1.standard (Google's) in a different cloud, meaning
> something completely different?

As stated in the proposal, the degree to which behaviour differs
surprisingly is in the degree of difference between homonymous instance
types on different clouds. My assertion is that this drawback is
insignificant in the face of the advantages; both the positive and
negative features of my proposal, including the one you cite, were
discussed in some detail in my original email, and advanced as a serious
proposal on the strength of my analysis.

Your communication leaves me with the impression that you believe my
arguments to be flawed in some way; I am keen to be corrected, but there
seems to be no avenue by which we can explore this possibility without
my repeating myself. If you in turn feel that I have not properly
addressed the costs and benefits of your ec2-type proposal, I apologise;
perhaps I don't understand it properly?

> If we can't solve these simple issues, my suggestion would be not
> doing anything about instance type right now, so the feature can get
> out of the ground at least.

I am again left with the impression that you find my analysis of the
problem and/or proposed solution to be lacking, but I'm not sure in what
respect it falls short. Would you explain in a little more detail
please?

Cheers
William