Open Stack

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 <adrian.otto at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best wishes!
Baohua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/c86e9571/attachment.html>