On 10/09/2015 01:39 PM, David Stanek wrote:
On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx <j...@csail.mit.edu
<mailto: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
<mailto: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
<mailto: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
<http://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 <http://tcp.example.com>
-vs-
_compute._tcp.regionone.example.com <http://tcp.regionone.example.com>
Also not all operators can controll their DNS to this level so it
couldn't be the only option.
SO - XMPP does this. The way it works is that if your XMPP provider has
put the approriate records in DNS, then everything Just Works. If not,
then you, as a consumer, have several pieces of information you need to
provide by hand.
Of course, there are already several pieces of information you have to
provide by hand to connect to OpenStack, so needing to download a
manifest file or something like that to talk to a cloud in an
environment where the people running a cloud do not have the ability to
add information to DNS (boggles) shouldn't be that terrible.
One could also imagine an in-between option where OpenStack could run an
_optional_ DNS for this purpose - and then the only 'by-hand' you'd need
for clouds with no real DNS is the location of the discover DNS.
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
__________________________________________________________________________
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
