resource maps

William Reade william.reade at canonical.com
Mon May 21 16:35:21 UTC 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.

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

> > Field precedence strikes me as a little bit restrictive; I might easily
> > favour take 2+2048 over 4+1024, but that doesn't imply that 2+65536
> 
> That's exactly what I was pointing out above. I didn't mean "field
> precedence", but "precedence field".

Ah, cool, sorry about that.

Cheers
William




More information about the Juju mailing list