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 ________________________________ Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated.
__________________________________________________________________________ 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
