Quoting [Sam Johnston] (Apr 16 2009):
Again, taking the more general approach, we suggest that servers should be specified in terms of continuous quantities of CPU, RAM and disk, with a provider 'rounding up' to the nearest available specification if their granularity is coarser than the standard API.
I'm not sure about rounding up as such - feels a bit messy (exceed the limit by 1 byte and your cost will double for example). If the provider has templates these should be advertised but ultimately it's up to the implementor to decide whether to reject a request for an unsupported configuration with an error or whether to satisfy it anyway with a larger device.
I think you should not leave that to the implementor, really - there is a significant semantic uncertainty in the API when you leave 'minimal resource requirements' versus 'exact resource requirements' unspecified. Exact requirements avoid the pricing pitfalls you mention. Minimal requirements are more flexible, and probably more interoperable. As I assume the user has to control pricing out of bound (i.e. outside of this API) anyway, I'd vote for the minimal spec approach. My $0.02, Andre.
I think the key thing for most of these points is giving implementors flexibility without sacrificing interoperability, and fortunately I think we can have our cake and eat it here.
Sam
-- Nothing is ever easy.