[openstack-dev] [magnum] Nesting /containers resource under /bays

Ryan Brown rybrown at redhat.com
Wed Jan 13 21:16:54 UTC 2016


On 01/13/2016 04:42 AM, Jamie Hannaford wrote:
> I've recently been gathering feedback about the Magnum API and one of
> the things that people commented on​ was the global /containers
> endpoints. One person highlighted the danger of UUID collisions:
>
>
> """
>
> It takes a container ID which is intended to be unique within that
> individual cluster. Perhaps this doesn't matter, considering the surface
> for hash collisions. You're running a 1% risk of collision on the
> shorthand container IDs:
>
>
> In [14]: n = lambda p,H: math.sqrt(2*H * math.log(1/(1-p)))
>
> In [15]: n(.01, 0x1000000000000)
> Out[15]: 2378620.6298183016
>
>
> (this comes from the Birthday Attack -
> https://en.wikipedia.org/wiki/Birthday_attack)
> <https://en.wikipedia.org/wiki/Birthday_attack>
>
>
> The main reason I questioned this is that we're not in control of how
> the hashes are created whereas each Docker node or Swarm cluster will
> pick a new ID under collisions. We don't have that guarantee when
> aggregating across.
>
>
> The use case that was outlined appears to be aggregation and reporting.
> That can be done in a different manner than programmatic access to
> single containers.​
>
> """
>
>
> Representing a resource without reference to its parent resource also
> goes against the convention of many other OpenStack APIs.
>
>
> Nesting a container resource under its parent bay would mitigate both of
> these issues:
>
>
> /bays/{uuid}/containers/{uuid}​
>
>
> I'd like to get feedback from folks in the Magnum team and see if
> anybody has differing opinions about this.
>
>
> Jamie

I'm not a member of the Magnum community, but I am on the API working 
group, so my opinions come from a slightly different perspective.

Nesting resources is not a "bad" thing, and as long as containers will 
always be in bays (from what I understand of the Magnum architecture, 
this is indeed true) then nesting them makes sense.

Of course, it's a big change and will have to be communicated to users & 
client libraries, probably via a version bump.

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.



More information about the OpenStack-dev mailing list