Open Stack

On Sat, Jun 15, 2013 at 11:00 PM, Ryan Lane <rlane at wikimedia.org> wrote:

> On Sat, Jun 15, 2013 at 6:37 PM, Monty Taylor <mordred at inaugust.com>wrote:
>
>>
>>
>> On 06/10/2013 10:49 AM, Mac Innes, Kiall wrote:
>> > On 10/06/13 15:20, Jeremy Stanley wrote:
>> >> On 2013-06-10 13:30:26 +0000 (+0000), Mac Innes, Kiall wrote:
>> >> [...]
>> >>> DNS on the other hand is about deciding where to send those bits
>> >> [...]
>> >>
>> >> And even that is a very understated description, focusing on
>> >> network-related applications of DNS.
>> >
>> > Absolutely - DNS is used for all sorts of purposes.
>> >
>> > Some interesting use cases are service discovery[1], replacing the
>> > traditional model of trust in browsers for HTTPS[2], authenticating
>> > email with DKIM[3], establishing SSH host key trust[4], aiding in the
>> > prevention of spam[5].. and many many more. Not all these examples are
>> > practical today, but they do provide examples of DNS functions which are
>> > outside the scope of OpenStack Networking.
>>
>> SO - As a huge supporter of using dns for things (since it's the world's
>> most scalable database), can I turn this around a little bit?
>>
>> Why don't we use DNS and/or a DNSaaS implementation to do the things in
>> the list that are above that are currently keystone's job in openstack?
>> Or, stated differently, why isn't this part of keystone, or keystone
>> part of this? It seems like some of the things that keystone needs to do
>> moving forward (global registry) have been working in the DNS for, well,
>> a long time...
>>
>>
> If you use OpenStack you have no choice but to use Keystone. This isn't
> really the case with Designate, and I think it would be difficult for it to
> be a required service. Maybe Keystone could have a driver that interacts
> with Designate for global registry, if Designate is being used?
>

+1 to all of the above; at the havana summit, we agreed that it would be a
great first step (and hopefully an easy one) to have a read-only service
catalog driver that acts as a client to moniker/designate (via HTTP or DNS).

Related- we're also working to (optionally) remove the service catalog from
the token itself, which will free up clients to make their own decisions
about how/where they discover services.
https://blueprints.launchpad.net/keystone/+spec/catalog-optional


>
> It really makes sense for this to be a standalone service that other
> services interact with. It's very possible that some infrastructures may
> choose to use Designate to manage their DNS without using any other
> OpenStack service.
>
> - Ryan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130616/c3d9937c/attachment.html>