resource maps

William Reade william.reade at canonical.com
Mon May 21 18:12:12 UTC 2012


On Mon, 2012-05-21 at 10:47 -0700, Clint Byrum wrote:
> 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.

The issue is that we're *already* using cost to select among the various
EC2 instance types that technically fulfil a set of constraints. I don't
think people would have been happy if we hadn't done that in the first
place [0], and I don't think we can really drop it now; and I don't
think we should use a separate mechanism for this aspect of it, because
the point of this feature is to avoid the hardcoding and special-casing
of EC2 in the first place ;).

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

Exactly :). "money" is not the only meaning for that field, but I don't
think it's a good idea to make it *inconvenient* to store money values
in there (ok, I *could* price ec2 in mUSDph to get ints, but...).

Cheers
William

[0] If I misjudged that: sorry :(.




More information about the Juju mailing list