[openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs
jaypipes at gmail.com
Mon Nov 17 22:08:33 UTC 2014
On 11/17/2014 04:46 PM, Amit Gandhi wrote:
> I can see where this makes a lot of sense in API¹s such as Nova¹s where
> flavors represent some combination of memory, disk, and cpu performance.
> In the case of CDN, the flavor represents a list of CDN providers.
In that case, your API is leaking implementation details.
> So... you could have a flavor representing a region of the world
> (America¹s) consisting of one or more CDN providers with a strong presence
> in those regions.
> Or a flavor could represent performance or features offered (number of
> edge nodes, speed, etc). And it is up to the operator to define those
> flavors and assign one or more appropriate CDN providers to those flavors.
Nothing above is different from Nova's flavors, other than the lack of
leaking driver implementation details.
> Im not sure decomposing the flavor in this context makes as much sense.
If you can't decompose the flavor into a set of capabilities that are
standardized across deployers of the Poppy API, then you have an API
that cannot be interoperable across deployers.
> On 11/17/14, 3:18 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>> I personally do not think that a "flavor" should be stored in the base
>> resource. The "flavor" should instead be decomposed into its composite
>> pieces (the specification for the CDN creation) and those pieces stored
>> in the database.
>> That way, you don't inherit the terrible problem that Nova has where
>> you're never really able to delete a flavor because some instance
>> somewhere may still be referring to it. If, in Nova, we decomposed the
>> flavor into all of its requisite pieces -- requested resource amounts,
>> requested "extra specs" capabilities, requested NUMA topology, etc -- we
>> wouldn't have this problem at all.
>> So, therefore my advice would be to not do any of the above and don't
>> have anything other than a "CDN type" or "CDN template" object that is
>> just deconstructed into the requested capabilities and resources of the
>> to-be-created CDN object and send along those things instead of
>> referring to some "flavor" thing.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev