<div dir="ltr"><div style>Just put here for more comments, thanks!<br></div><div style><br></div><div style><div>IMHO, there are three different options, worth discussion before the designing: </div><div>#Opt 1: Magnum as the API. The entire driver layer still leverages the third-party solutions like swarm or <span id="0f50f2d9-0cce-452a-acd9-f730adc088d4" class="GINGER_SOFTWARE_mark">kubernetes</span>, 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.</div><div>#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.</div><div>#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.</div><div><br></div><div>Finally, after investigating most existing open source container networking mechanisms, overlay is the common idea, where Neutron seems a good candidate.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 13, 2015 at 2:22 AM, Adrian Otto <span dir="ltr"><<a href="mailto:adrian.otto@rackspace.com" target="_blank">adrian.otto@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div>Team,</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div><a href="https://blueprints.launchpad.net/magnum/+spec/native-docker-network" target="_blank">https://blueprints.launchpad.net/magnum/+spec/native-docker-network</a></div>
<div><br>
</div>
<div>Before we dive into implementation planning, I'll offer these as guardrails to use as a starting point:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>References:</div>
<div>[1] <a href="https://github.com/docker/libnetwork" target="_blank">https://github.com/docker/libnetwork</a></div>
<div><br>
</div>
<div>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.</div><span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>Adrian</div>
</font></span></div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#999999">Best wishes!<br>Baohua<br></font></div>
</div>