Open Stack

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