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.
__________________________________________________________________________
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