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.
Best,
-jay
Amit.
On 11/17/14, 3:18 PM, "Jay Pipes" <jaypi...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
