Swarm already supports etcd as a discovery backend [1]. So we can implement both hosted discovery with Docker Hub and using name etcd. And make hosted discovery with Docker Hub default if discovery_url is not given.
If we run etcd in bay, etcd alse need discovery [2]. Operator should set up a etcd cluster for other etcd clusters to discover or use public discovery service. I think it is not necessary to run etcd in swarm cluster just for discovery service. In a private cloud, operator should set up a local etcd cluster for discovery service, and all the bays can use it. [1] https://docs.docker.com/swarm/discovery/ [2] https://github.com/coreos/etcd/blob/master/Documentation/clustering.md Regards, Wanghua On Fri, Sep 18, 2015 at 11:39 AM, Adrian Otto <adrian.o...@rackspace.com> wrote: > 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 >
__________________________________________________________________________ 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
