resource maps

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


On Mon, 2012-05-21 at 10:02 -0300, Gustavo Niemeyer wrote:
> On Mon, May 21, 2012 at 7:28 AM, William Reade
> <william.reade at canonical.com> wrote:
> > It seems to me that the simplest option is to expose "cost", treat empty
> > costs as 0, and choose arbitrarily between equally-cheap options; it
> > solves the problem we have now, and doesn't tempt us to define an ad-hoc
> > weighted feature-cost-ranking algorithm which would IMO become a
> > millstone (or irritate users when we inevitably tweak it).
> 
> I actually find such a precedence setting attractive. It allows us to
> define ordering so that conflicts may be solved (is it cheaper to run
> 2 CPU + 2048 GB of memory or 4 CPU + 1024 GB of memory?) without
> attempting to get onto cost issues. Such a weighting value will remain
> valid for longer, while prices devalue and get out of date with time
> (AWS prices change somewhat frequently).

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.

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
would be cheaper; and even defining cost-per-unit-per-feature seems
inappropriate [0], because I don't think that the relative weightings
will actually be linear in any but the most idealised scenarios.

Therefore, IMO, a plain unitless "cost" field can (1) be ignored by
anyone with (sufficiently) homogeneous hardware and (2) allow for
subtler distinctions than we can expose cleanly on a per-feature basis.
Thoughts?

Cheers
William




More information about the Juju mailing list