<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi Devs,<br>
</p>
<p><br>
</p>
<p>I'd like to get some discussion going for possible improvements to the</p>
<p>discovery <span style="font-size:12pt">mechanism used in Magnum's Swarm bay.</span></p>
<p><br>
</p>
<p>The method of the existing review[1] is to use the public swarm discovery</p>
<p>endpoint, <span style="font-size:12pt">and let the user pass a token in on the bay-create call. This is</span></p>
<p>definitely not ideal for a couple reasons. First, it requires the user to go<br>
</p>
<p>out and request that token themselves. Secondly, it relies on having<br>
</p>
<p>access to the internet and public swarm discovery endpoint.<br>
</p>
<p><br>
</p>
<p>Solving the first issue is fairly simple, the TemplateDefinition could request<br>
</p>
<p>the token just like the CoreOS TemplateDefinition does. That still <span style="font-size:12pt">requires</span></p>
<p><span style="font-size:12pt">not only M</span><span style="font-size:12pt">agnum but also all of the instances in the Bay have access to the</span></p>
<p><span style="font-size:12pt">public discovery endpoint. I still think this option has some merit for some</span></p>
<p><span style="font-size:12pt">cases, how many of our users will be running their bays in isolation without</span></p>
<p><span style="font-size:12pt">access to Docker's public services (registry/hub/discovery).</span></p>
<p><span style="font-size:12pt"><br>
</span></p>
<p><span style="font-size:12pt">Solving the second issue is going to be a bit more complex. Swarm does </span></p>
<p><span style="font-size:12pt">provide multiple alternatives to public token based discovery [2]. These</span></p>
<p><span style="font-size:12pt">revolve around either static lists of hosts, or around other configuration</span></p>
<p><span style="font-size:12pt">services like etcd. Static lists of hosts is going to make growing or shrinking</span></p>
<p><span style="font-size:12pt">bays a real pain. I think the best option here is to go with a configuration</span></p>
<p><span style="font-size:12pt">service.</span></p>
<p><span style="font-size:12pt"><br>
</span></p>
<p><span style="font-size:12pt">Configuration services present their own issues. Should each bay host it's</span></p>
<p>own service, similar to how we're doing for the swarm manager and agents.<br>
</p>
<p>Or, should it be up to the operator to run a global configuration service and<br>
</p>
<p>each bay will use some unique ID (Bay UUID may work here) for discovery.<br>
</p>
<p>Running a service inside each bay will likely require a different template for<br>
</p>
<p>each type of service, and will add more services to each Bay that may need<br>
</p>
<p>to be maintained. Due to that, the simpler solution may be to rely on the<br>
</p>
<p>operator to run a global service.<br>
</p>
<p><br>
</p>
<p>Anyways, any thoughts here will be greatly appreciated!<br>
</p>
<p><br>
</p>
<p>Thanks!<br>
</p>
<p>Andrew<br>
</p>
<p><br>
</p>
<p>[1]: <a href="https://review.openstack.org/#/c/174112">https://review.openstack.org/#/c/174112</a><br>
</p>
<p>[2]: <a href="https://github.com/docker/swarm/blob/master/discovery/README.md">https://github.com/docker/swarm/blob/master/discovery/README.md</a><br>
</p>
</body>
</html>