resource maps

[Clint Byrum]

Excerpts from William Reade's message of Mon May 21 09:35:21 -0700 2012:
> On Mon, 2012-05-21 at 13:03 -0300, Gustavo Niemeyer wrote:
> > > I don't think I was quite clear about cost: it's intended more as a
> > > measure of relative opportunity cost than of actual currency. So, it's
> > > convenient but coincidental that it happens to map onto USDph in the
> > > example given.
> > 
> > A "cost" setting that "happens to map to USD" feels like a weak
> > concept that will certainly be misunderstood and misused. We could
> > solve the problem with a "precedence" setting which is an integer that
> > defines ordering, and document it as such.
> 
> I have two quibbles here:
> 
> 1) "precedence" feels to me like "priority" in that I'm not aware of a
> global agreement that defines whether 1 is higher priority than 5; while
> there is (I think) a bit more of a general agreement that (1) cost is
> not just monetary and (2) lower cost solutions are better, all other
> things being equal.
> 

At the risk of confusing the issue by re-using a word in-play.. there
is precedence for using cost. Routing cost has long been understood not
to mean dollars.

However, in this sense, routes are essentially a finite resource. You
are just choosing the higher cost route when the lower cost one is
not available.

With bare metal, this is a valid approach but not one that I think many
users would appreciate. "Well you didn't have any low cost nodes available
so I grabbed this 20000.00 node for you to run your blog on instead".

With the cloud, cost of instance has an entirely different meaning. Its
no longer a fixed one time cost, but ongoing rate. This means it may
be better to choose a high cost in the short term if it offers more
value and can save you time. Also as opposed to the bare metal system,
you don't get the "cost" back when you de-allocate the instance.

Anyway, I don't think this can be just one field. If you call it 'order'
instead of 'cost', you put things on a linear scale with no guidance as
to why one thing should be equal to or above another. Amazon's instance
types are not linear, and neither are HP's proliant servers. Using cost,
and making it dollars per hour at least is rooted in a real, defined
thing, and so can at least be used without any further interpretation
of what it actually means.

IMO, this shows that the whole field, no matter what it is named, should
be left out of the specification at this juncture. We are not developing
any constraints that will interpret this at this time. When it is time to
add that feature, thats when its time to specify this bit of the resource
map.  It will become much more clear what the appropriate terminology
and value type is when we have real use cases.

> 2) I don't think we gain anything by using ints over floats... if we use
> floats, people can still use use ints if they want; and if we don't use
> floats, we lose (1) the ability to clearly express relative costs and
> (2) the ability to easily insert new instance-types which are in the
> middle of the existing ranking. (And I've never really liked numbering
> things 10, 20, 30 etc just to allow for future expansion... it feels
> entirely too reminiscent of BASIC, and I'd rather not promote that sort
> of behaviour unless there's no clean alternative ;).)

FTR, if this goes forward (order, cost, etc), +1 for floats. I can't see
any value to simplifying to ints, other than to remove confusion with
"money". However, in some instances, money will be the exact measure that
is needed, and exchange rates and as-yet-unseen cheap resources (hint:
tiny arm cpus?) may call for much deeper than even 2 decimal places.