Open Stack

In short, the container IDs assigned by Magnum are independent of the container IDs assigned by Docker daemon. Magnum do the IDs mapping before doing a native API call. In particular, here is how it works.

If users create a container through Magnum endpoint, Magnum will do the followings:

1.       Generate a uuid (if not provided).

2.       Call Docker Swarm API to create a container, with its hostname equal to the generated uuid.

3.       Persist container to DB with the generated uuid.

If users perform an operation on an existing container, they must provide the uuid (or the name) of the container (if name is provided, it will be used to lookup the uuid). Magnum will do the followings:

1.       Call Docker Swarm API to list all containers.

2.       Find the container whose hostname is equal to the provided uuid, record its “docker_id” that is the ID assigned by native tool.

3.       Call Docker Swarm API with “docker_id” to perform the operation.

Magnum doesn’t assume all operations to be routed through Magnum endpoints. Alternatively, users can directly call the native APIs. In this case, the created resources are not managed by Magnum and won’t be accessible through Magnum’s endpoints.

Hope it is clear.

Best regards,
Hongbin

From: Kyle Kelley [mailto:kyle.kelley at RACKSPACE.COM]
Sent: January-14-16 11:39 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays


This presumes a model where Magnum is in complete control of the IDs of individual containers. How does this work with the Docker daemon?



> In Rest API, you can set the “uuid” field in the json request body (this is not supported in CLI, but it is an easy add).​



In the Rest API for Magnum or Docker? Has Magnum completely broken away from exposing native tooling - are all container operations assumed to be routed through Magnum endpoints?



> For the idea of nesting container resource, I prefer not to do that if there are alternatives or it can be work around. IMO, it sets a limitation that a container must have a bay, which might not be the case in future. For example, we might add a feature that creating a container will automatically create a bay. If a container must have a bay on creation, such feature is impossible.



If that's *really* a feature you need and are fully involved in designing for, this seems like a case where creating a container via these endpoints would create a bay and return the full resource+subresource.



Personally, I think these COE endpoints need to not be in the main spec, to reduce the surface area until these are put into further use.







________________________________
From: Hongbin Lu <hongbin.lu at huawei.com<mailto:hongbin.lu at huawei.com>>
Sent: Wednesday, January 13, 2016 5:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Hi Jamie,

I would like to clarify several things.

First, a container uuid is intended to be unique globally (not within individual cluster). If you create a container with duplicated uuid, the creation will fail regardless of its bay. Second, you are in control of the uuid of the container that you are going to create. In Rest API, you can set the “uuid” field in the json request body (this is not supported in CLI, but it is an easy add). If a uuid is provided, Magnum will use it as the uuid of the container (instead of generating a new uuid).

For the idea of nesting container resource, I prefer not to do that if there are alternatives or it can be work around. IMO, it sets a limitation that a container must have a bay, which might not be the case in future. For example, we might add a feature that creating a container will automatically create a bay. If a container must have a bay on creation, such feature is impossible.

Best regards,
Hongbin

From: Jamie Hannaford [mailto:jamie.hannaford at rackspace.com]
Sent: January-13-16 4:43 AM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [magnum] Nesting /containers resource under /bays


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<http://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 abuse at rackspace.com<mailto:abuse at rackspace.com> and delete the original message. Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160114/855cdc0e/attachment-0001.html>