In the case where a private cloud is used without access to the Internet, you do have the option of running your own etcd, and configuring that to be used instead.
Adding etcd to every bay should be optional, as a subsequent feature, but should be controlled by a flag in the Baymodel that defaults to off so the public discovery service is used. It might be nice to be able to configure Magnum in an isolated mode which would change the system level default for that flag from off to on. Maybe the Baymodel resource attribute should be named local_discovery_service. Should turning this on also set the minimum node count for the bay to 3? If not, etcd will not be highly available. Adrian > On Sep 17, 2015, at 1:01 PM, Egor Guz <e...@walmartlabs.com> wrote: > > +1 for stop using public discovery endpoint, most private cloud vms doesn’t > have access to internet and operator must to run etcd instance somewhere just > for discovery. > > — > Egor > > From: Andrew Melton > <andrew.mel...@rackspace.com<mailto:andrew.mel...@rackspace.com>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> > Date: Thursday, September 17, 2015 at 12:06 > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> > Subject: Re: [openstack-dev] [magnum] Discovery > > > 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<mailto: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 __________________________________________________________________________ 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
