Open Stack

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.otto at 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 <EGuz at 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.melton at RACKSPACE.COM<mailto:
> andrew.melton at RACKSPACE.COM>>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org<mailto:
> openstack-dev at lists.openstack.org>>
> > Date: Thursday, September 17, 2015 at 12:06
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at 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) <danehans at cisco.com<mailto:
> danehans at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150921/f89429b5/attachment.html>