constraints call notes/proposals/sync

[Gustavo Niemeyer]

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.

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.

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

>   * 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?

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.


gustavo @ http://niemeyer.net