Hey Daneyon,

I'm fairly partial towards #2 as well. Though, I'm wondering if it's possible 
to take it a step further. Could we run etcd in each Bay without using the 
public discovery endpoint? And then, configure Swarm to simply use the internal 
ectd as it's discovery mechanism? This could cut one of our external service 
dependencies and make it easier to run Magnum is an environment with locked 
down public internet access.?


Anyways, I think #2 could be a good start that we could iterate on later if 
need be.


--Andrew


________________________________
From: Daneyon Hansen (danehans) <daneh...@cisco.com>
Sent: Wednesday, September 16, 2015 11:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Discovery

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

Reply via email to