Open Stack

All,

While implementing the flannel --network-driver for swarm, I have come across an issue that requires feedback from the community. Here is the breakdown of the issue:

  1.  Flannel [1] requires etcd to store network configuration. Meeting this requirement is simple for the kubernetes bay types since kubernetes requires etcd.
  2.  A discovery process is needed for bootstrapping etcd. Magnum implements the public discovery option [2].
  3.  A discovery process is also required to bootstrap a swarm bay type. Again, Magnum implements a publicly hosted (Docker Hub) option [3].
  4.  Magnum API exposes the discovery_url attribute that is leveraged by swarm and etcd discovery.
  5.  Etcd can not be implemented in swarm because discovery_url is associated to swarm’s discovery process and not etcd.

Here are a few options on how to overcome this obstacle:

  1.  Make the discovery_url more specific, for example etcd_discovery_url and swarm_discovery_url. However, this option would needlessly expose both discovery url’s to all bay types.
  2.  Swarm supports etcd as a discovery backend. This would mean discovery is similar for both bay types. With both bay types using the same mechanism for discovery, it will be easier to provide a private discovery option in the future.
  3.  Do not support flannel as a network-driver for k8s bay types. This would require adding support for a different driver that supports multi-host networking such as libnetwork. Note: libnetwork is only implemented in the Docker experimental release: https://github.com/docker/docker/tree/master/experimental.

I lean towards #2 but their may be other options, so feel free to share your thoughts. I would like to obtain feedback from the community before proceeding in a particular direction.

[1] https://github.com/coreos/flannel
[2] https://github.com/coreos/etcd/blob/master/Documentation/discovery_protocol.md
[3] https://docs.docker.com/swarm/discovery/

Regards,
Daneyon Hansen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150916/6ee5e85a/attachment.html>