<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx <span dir="ltr"><<a href="mailto:jon@csail.mit.edu" target="_blank">jon@csail.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote:<br>
<span class="">:> On Oct 9, 2015, at 12:28 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
:><br>
:>> On 10/09/2015 11:21 AM, Shamail wrote:<br>
:>><br>
:>><br>
:>>> On Oct 9, 2015, at 10:39 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
:>>><br>
:>>> It looks like some great conversation got going on the service catalog<br>
:>>> standardization spec / discussion at the last cross project meeting.<br>
:>>> Sorry I wasn't there to participate.<br>
:>> Apologize if this is a question that has already been address but why can't we just leverage something like <a href="http://consul.io" rel="noreferrer" target="_blank">consul.io</a>?<br>
:><br>
:> It's a good question and there have actually been some discussions about leveraging it on the backend. However, even if we did, we'd still need keystone to provide the multi-tenancy view on the subject. consul wasn't designed (quite correctly I think) to be a user-facing service for 50k users.<br>
:><br>
:> I think it would be an excellent backend.<br>
:Thanks, that makes sense.  I agree that it might be a good backend but not the overall solution... I was bringing it up to ensure we consider existing options (where possible) and spend cycles on the unsolved bits.<br>
<br>
</span>As an operator I'd be happy to use SRV records to define endpoints,<br>
though multiple regions could make that messy.<br>
<br>
would we make subdomins per region or include region name in the<br>
service name?<br>
<br>
_compute-regionone._<a href="http://tcp.example.com" rel="noreferrer" target="_blank">tcp.example.com</a><br>
               -vs-<br>
_compute._<a href="http://tcp.regionone.example.com" rel="noreferrer" target="_blank">tcp.regionone.example.com</a><br>
<br>
Also not all operators can controll their DNS to this level so it<br>
couldn't be the only option.<br>
<br>
Or are you talking about using an internal DNS implementation private<br>
to the OpenStack Deployment?  I'm actually a bit less happy with that<br>
idea.<br></blockquote><div><br></div><div>I was able to put together an implementation[1] of DNS-SD loosely based on RFC-6763[2]. It'd really a proof of concept, but we've talked so much about it that I decided to get something working. Although if this seems like a viable option then there's still much work to be done.</div><div><br></div><div>I'd love feedback. </div><div><br></div><div>1. <a href="https://gist.github.com/dstanek/093f851fdea8ebfd893d">https://gist.github.com/dstanek/093f851fdea8ebfd893d</a></div><div>2. <a href="https://tools.ietf.org/html/rfc6763">https://tools.ietf.org/html/rfc6763</a></div></div><div><br></div>-- <br><div class="gmail_signature">David<br>blog: <a href="http://www.traceback.org" target="_blank">http://www.traceback.org</a><br>twitter: <a href="http://twitter.com/dstanek" target="_blank">http://twitter.com/dstanek</a><div>www: <a href="http://dstanek.com" target="_blank">http://dstanek.com</a></div></div>
</div></div>