Open Stack

On 10/09/2015 01:39 PM, David Stanek wrote:
>
> On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx <jon at csail.mit.edu
> <mailto:jon at 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 <mordred at inaugust.com
>     <mailto:mordred at inaugust.com>> wrote:
>     :>
>     :>> On 10/09/2015 11:21 AM, Shamail wrote:
>     :>>
>     :>>
>     :>>> On Oct 9, 2015, at 10:39 AM, Sean Dague <sean at dague.net
>     <mailto:sean at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>