2016-08-05 21:16 GMT+08:00 Chris Dent <cdent...@anticdent.org>: > On Tue, 2 Aug 2016, Alex Xu wrote: > > Chris have a thought about using ResourceClass to describe Capabilities >> with an infinite inventory. In the beginning we brain storming the idea of >> Tags, Tan Lin have same thought, but we say no very quickly, due to the >> ResourceClass is really about Quantitative stuff. But Chris give very good >> point about simplify the ResourceProvider model and the API. >> > > I'm still leaning in this direction. I realized I wasn't explaining > myself very well and "because I like it" isn't really a good enough > for doing anything, so I wrote something up about it: > > https://anticdent.org/simple-resource-provision.html > > Reusing the existing infrastructure of resource classes, inventories and allocations does make implementation easier with capabilities as well as their calculations and representations, at least at the beginning.
But I'm still not convinced by this direction, because it introduces unnecessary reuses as well as overhead for capabilities. Instead of attaching a capability directly to a resource provider, it needs to create an inventory and assign the capability to inventory, indirectly. Moreover, it reuses allocations and even the "compare-and-swap" strategy with the implementation of "generation" field in the resource provider. And it introduces further complexities and obscurities if we decide to disable the unnecessary consumable features for capabilities. The existing architecture of resource provider is mainly for consumable resources. And we don't want capabilities to be consumable by mistake. It is an inherently different implementation for non consumable capabilities, so I tend to agree to implement qualitative part of resource provider from a fresher start to keep it simple and direct. And add features incrementally if they are thought necessary. --- Regards Yingxin
__________________________________________________________________________ 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
