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
__________________________________________________________________________ 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
