<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
Andrew,
<div><br>
</div>
<div>For clustered services that require generation of a discovery token, and access to a discovery service, we need to keep in mind a few things:</div>
<div><br>
</div>
<div>1) Cloud operators have their own preferences for what defaults should be use. Some may want to run their own discovery services, and others will not.</div>
<div><br>
</div>
<div>2) Users may not want to use a discovery service offered by his or her cloud provider. They may want to run their own.</div>
<div><br>
</div>
<div>3) We do not want the burden for running Magnum to be any higher than it has to be. We should not require cloud operators to also run discovery services in order to use Magnum if they are willing to rely on the public discovery services.</div>
<div><br>
</div>
<div>So I propose the following:</div>
<div><br>
</div>
<div>* The address for the discovery service should be set using a magnum configuration directive to be set in magnum.conf.</div>
<div>* The value of this configuration directive should default to the public discovery service.</div>
<div>* The Bay Create call should allow a parameter to allow the user to supply his/her own value to use for this setting.</div>
<div><br>
</div>
<div>This approach addresses all three concerns laid out above. The same approach should apply both to CoreOS and Swarm Bay so the user experience is consistent.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Adrian</div>
<div><br>
<div>
<div>
<div>On Apr 16, 2015, at 12:31 PM, Andrew Melton <<a href="mailto:andrew.melton@RACKSPACE.COM">andrew.melton@RACKSPACE.COM</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
<div dir="ltr" style="font-size: 12pt; background-color: rgb(255, 255, 255); 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>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>