Re: [openstack-dev] [Magnum] Docker Native Networking
Team, This blueprint needs an assignee: https://blueprints.launchpad.net/magnum/+spec/native-docker-network I have moved the whiteboard discussion to the etherpad: https://etherpad.openstack.org/p/magnum-native-docker-network Please take a moment to put your input on the ether pad so we can draft an actionable plan for getting this feature going. Thanks, Adrian On Jun 12, 2015, at 11:05 AM, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Team, OpenStack Networking support for Magnum Bays was an important topic for us in Vancouver at the design summit. Here is one blueprint that requires discussion that’s beyond the scope of what we can easily fit in the BP whiteboard: https://blueprints.launchpad.net/magnum/+spec/native-docker-network Before we dive into implementation planning, I'll offer these as guardrails to use as a starting point: 1) Users of the Swarm bay type have the ability to create containers. Those containers may reside on different hosts (Nova instances). We want those containers to be able to communicate with each other over a network similar to the way that they can over the Flannel network used with Kubernetes. 2) We should leverage community work as much as possible, combining the best of Docker and OpenStack to produce an integrated solution that is easy to use, and exhibits performance that's suitable for common use cases. 3) Recognize that our Docker community is working on libnetwork [1] which will allow for the creation of logical "networks" similar to "links" that allow containers to communicate with each other across host boundaries. The implementation is pluggable, and we decided in Vancouver that working on a Neutron plugin for libnetwork could potentially make the user experience consistent whether you are using Docker within Magnum or not. 4) We would like to plug in Neutron to Flannel as a modular option for Kubernetes Bays, so both solutions leverage OpenStack networking, and users can use familiar, native tools. References: [1] https://github.com/docker/libnetwork Please let me know what you think of this approach. I’d like to re-state the Blueprint description, clear the whiteboard, and put up a spec that will accommodate in-line comments so we can work on the implementation specifics better in context. Adrian __ 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
Re: [openstack-dev] [Magnum] Docker Native Networking
Just put here for more comments, thanks! IMHO, there are three different options, worth discussion before the designing: #Opt 1: Magnum as the API. The entire driver layer still leverages the third-party solutions like swarm or kubernetes, then we have to keep compatible with their limitation in networking. This will be quick to implement, but inflexible in networking capacities. This is the traditional way, easy for now, but hard for the future. #Opt 2: Magnum as the Engine. We only leverage third-party drivers to manage the lifestyle of containers, but utilize the OpenStack mechanism (i.e., Neutron) to handle the networking. This need investigation into the possibility of combination in different environments. This can target to combine the best of Docker and OpenStack. #Opt 3: Magnum as the Solution. Besides the third-party drivers, we design our own container provision mechanism (Not Nova-Docker), then it will be more fluent to integrate with Neutron. However, this need to design new naive driver layer (Docker+Flannel is a good reference, as the design idea is similar and simpler with Neutron). This is the most clean option. Finally, after investigating most existing open source container networking mechanisms, overlay is the common idea, where Neutron seems a good candidate. On Sat, Jun 13, 2015 at 2:22 AM, Adrian Otto wrote: > Team, > > OpenStack Networking support for Magnum Bays was an important topic for > us in Vancouver at the design summit. Here is one blueprint that requires > discussion that’s beyond the scope of what we can easily fit in the BP > whiteboard: > > https://blueprints.launchpad.net/magnum/+spec/native-docker-network > > Before we dive into implementation planning, I'll offer these as > guardrails to use as a starting point: > > 1) Users of the Swarm bay type have the ability to create containers. > Those containers may reside on different hosts (Nova instances). We want > those containers to be able to communicate with each other over a network > similar to the way that they can over the Flannel network used with > Kubernetes. > > 2) We should leverage community work as much as possible, combining the > best of Docker and OpenStack to produce an integrated solution that is easy > to use, and exhibits performance that's suitable for common use cases. > > 3) Recognize that our Docker community is working on libnetwork [1] > which will allow for the creation of logical "networks" similar to "links" > that allow containers to communicate with each other across host > boundaries. The implementation is pluggable, and we decided in Vancouver > that working on a Neutron plugin for libnetwork could potentially make the > user experience consistent whether you are using Docker within Magnum or > not. > > 4) We would like to plug in Neutron to Flannel as a modular option for > Kubernetes Bays, so both solutions leverage OpenStack networking, and users > can use familiar, native tools. > > References: > [1] https://github.com/docker/libnetwork > > Please let me know what you think of this approach. I’d like to re-state > the Blueprint description, clear the whiteboard, and put up a spec that > will accommodate in-line comments so we can work on the implementation > specifics better in context. > > Adrian > > __ > 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 > > -- Best wishes! Baohua __ 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-dev] [Magnum] Docker Native Networking
Team, OpenStack Networking support for Magnum Bays was an important topic for us in Vancouver at the design summit. Here is one blueprint that requires discussion that’s beyond the scope of what we can easily fit in the BP whiteboard: https://blueprints.launchpad.net/magnum/+spec/native-docker-network Before we dive into implementation planning, I'll offer these as guardrails to use as a starting point: 1) Users of the Swarm bay type have the ability to create containers. Those containers may reside on different hosts (Nova instances). We want those containers to be able to communicate with each other over a network similar to the way that they can over the Flannel network used with Kubernetes. 2) We should leverage community work as much as possible, combining the best of Docker and OpenStack to produce an integrated solution that is easy to use, and exhibits performance that's suitable for common use cases. 3) Recognize that our Docker community is working on libnetwork [1] which will allow for the creation of logical "networks" similar to "links" that allow containers to communicate with each other across host boundaries. The implementation is pluggable, and we decided in Vancouver that working on a Neutron plugin for libnetwork could potentially make the user experience consistent whether you are using Docker within Magnum or not. 4) We would like to plug in Neutron to Flannel as a modular option for Kubernetes Bays, so both solutions leverage OpenStack networking, and users can use familiar, native tools. References: [1] https://github.com/docker/libnetwork Please let me know what you think of this approach. I’d like to re-state the Blueprint description, clear the whiteboard, and put up a spec that will accommodate in-line comments so we can work on the implementation specifics better in context. Adrian __ 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
