Open Stack

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 PM
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.​

Thanks for your feedback. #2 was the preferred direction of the Magnum Networking Subteam as well. Therefore, I have started working on [1] to move this option forward. As part of this effort, I am slightly refactoring the Swarm heat templates to more closely align them with the k8s templates. Until tcammann completes the larger template refactor [2], I think this will help dev’s more easily implement features across all bay types, distro’s, etc..

We can have etcd and Swarm use a local discovery backend. I have filed bp [3] to establish this effort. As a first step towards [3], I will modify Swarm to use etcd for discovery. However, etcd will still use public discovery for [1]. Either myself or someone from the community will need to attack etcd local discovery as a follow-on. For the longer-term, we may want to consider exposing a --discovery-backend attribute and optionally pass labels to allow users to modify default configurations of the —discovery-backend.

[1] https://review.openstack.org/#/c/224367/
[2] https://blueprints.launchpad.net/magnum/+spec/generate-heat-templates
[3] https://blueprints.launchpad.net/magnum/+spec/bay-type-discovery-options




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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/d5348de6/attachment.html>