What are the reasons for keeping /containers? On Fri, Jan 15, 2016 at 9:14 PM, Hongbin Lu <hongbin...@huawei.com> wrote:
> Disagree. > > > > If the container managing part is removed, Magnum is just a COE deployment > tool. This is really a scope-mismatch IMO. The middle ground I can see is > to have a flag that allows operators to turned off the container managing > part. If it is turned off, COEs are not managed by Magnum and requests sent > to the /container endpoint will return a reasonable error code. Thoughts? > > > > Best regards, > > Hongbin > > > > *From:* Mike Metral [mailto:mike.met...@rackspace.com] > *Sent:* January-15-16 6:24 PM > *To:* openstack-dev@lists.openstack.org > > *Subject:* Re: [openstack-dev] [magnum] Nesting /containers resource > under /bays > > > > I too believe that the /containers endpoint is obstructive to the overall > goal of Magnum. > > > > IMO, Magnum’s scope should *only* be concerned with: > > 1. Provisioning the underlying infrastructure required by the > Container Orchestration Engine (COE) and > 2. Instantiating the COE itself on top of said infrastructure from > step #1. > > Anything further regarding Magnum interfacing or interacting with > containers starts to get into a gray area that could easily evolve into: > > - Potential race conditions between Magnum and the designated COE and > - Would create design & implementation overhead and debt that could > bite us in the long run seeing how all COE’s operate & are based off > various different paradigms in terms of describing & managing containers, > and this divergence will only continue to grow with time. > - Not to mention, the recreation of functionality around managing > containers in Magnum seems redundant in nature as this is the very reason > to want to use a COE in the first place – because it’s a more suited tool > for the task > > If there is low-hanging fruit in terms of common functionality across > *all* COE’s, then those generic capabilities *could* be abstracted and > integrated into Magnum, but these have to be carefully examined beforehand > to ensure true parity exists for the capability across all COE’s. > > > > However, I still worry that going down this route toes the line that > Magnum should and could be a part of the managing container story to some > degree – which again should be the sole responsibility of the COE, not > Magnum. > > > > I’m in favor of doing away with the /containers endpoint – continuing with > it just looks like a snowball of scope-mismatch and management issues just > waiting to happen. > > > > Mike Metral > > Product Architect – Private Cloud R&D - Rackspace > ------------------------------ > > *From:* Hongbin Lu <hongbin...@huawei.com> > *Sent:* Thursday, January 14, 2016 1:59 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [magnum] Nesting /containers resource > under /bays > > > > 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.kel...@rackspace.com > <kyle.kel...@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...@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.hannaf...@rackspace.com > <jamie.hannaf...@rackspace.com>] > *Sent:* January-13-16 4:43 AM > *To:* openstack-dev@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 - 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 > > > > __________________________________________________________________________ > 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 > > -- Kyle Kelley (@rgbkrk <https://twitter.com/rgbkrk>; lambdaops.com)
__________________________________________________________________________ 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
