On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx <j...@csail.mit.edu> wrote:
> On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote: > :> On Oct 9, 2015, at 12:28 PM, Monty Taylor <mord...@inaugust.com> wrote: > :> > :>> On 10/09/2015 11:21 AM, Shamail wrote: > :>> > :>> > :>>> On Oct 9, 2015, at 10:39 AM, Sean Dague <s...@dague.net> wrote: > :>>> > :>>> It looks like some great conversation got going on the service catalog > :>>> standardization spec / discussion at the last cross project meeting. > :>>> Sorry I wasn't there to participate. > :>> Apologize if this is a question that has already been address but why > can't we just leverage something like consul.io? > :> > :> 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. > :> > :> I think it would be an excellent backend. > :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. > > As an operator I'd be happy to use SRV records to define endpoints, > though multiple regions could make that messy. > > would we make subdomins per region or include region name in the > service name? > > _compute-regionone._tcp.example.com > -vs- > _compute._tcp.regionone.example.com > > Also not all operators can controll their DNS to this level so it > couldn't be the only option. > > Or are you talking about using an internal DNS implementation private > to the OpenStack Deployment? I'm actually a bit less happy with that > idea. > 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. I'd love feedback. 1. https://gist.github.com/dstanek/093f851fdea8ebfd893d 2. https://tools.ietf.org/html/rfc6763 -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
