On Mon, 8 Aug 2016, Alex Xu wrote:
Chris, thanks for the blog to explain your idea! It helps me understand
your idea better.
Thanks for reading it. As I think I've mentioned a few times I'm not
really trying to sell the idea, just make sure it is clear enough to
be evaluated.
I agree the goal for API interface design in your blog. But one point I
guess you also agree, that is "The interface is easy to understand for API
user". So look at the example of API request flow with gabbi, it is pretty
clear for me even I didn't spend any time to learn the gabbi. That means:
gabbi is cool and the interface is clear! But the only confuse is "total:
∞". And the related ResourceClass is "ssd", does it mean disk size is
infinite? For a user, he is learning our API, he needs to search the
document, due to he want to know "what is this special usage way means to".
If user can understand our API without any document, so that is prefect.
I think the main source of confusion is that where I find it pretty
easy to think of qualitative characteristics as being an "infinity
of a quantity" that's not an easy concept in general.
In the "ssd" example what it means is not that disk size is infinite
but taht the ssd-ness of the resource provider is infinite. So, for
example a resource provider which provides disk space that is hosted
on ssd has (at least) two resource classes:
DISK_GB: <some value of gigabytes>
SSD: <an infinity of ssd-ness>
When some ssd-ness is consumed, all of it (infinity) is still left
over.
For me it is easier: a resource provider has just one way of
describing what it can do: classes of inventory (that provide
gigabytes of disk that are ssd). When we add tags/capabilities
we have another mode of description.
/me yields
--
Chris Dent ┬─┬ノ( º _ ºノ) http://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
