Open Stack

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:
> >
> > 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?



I agree there is a very interesting overlap between DNSaaS for customer
service discovery and openstack service discovery. Even if you are
uncomfortable with the idea of mixing in service and customer data (I kind
of am!), reuse might still make a ton of sense in a TripleO type of
deployment context.

I particularly like Monty's suggestion about using DNS to do some of the
service catalog functions that are currently Keystone's responsibility,
though I don't know enough about DNS to evaluate if this would be a good
choice in a technical sense. I'd rather have us focus service discovery
(both catalog and DNS) into the same project outside of Keystone than fold
DNSaaS into/under Keystone--it honestly makes very little sense to me to
include service catalogs with identity and policy. Including service
catalogs in token responses has some very unfortunate side effects:
   - service catalogs have to be small enough to fit into a single
response, sometimes even a single HTTP header if some service catalog data
ends up in pki tokens
   - service catalog views are always restricted to a specific project,
since a token is in general valid only for a specific project

These side effects make certain user experience stories really difficult,
for example, "List all instances I have permission to control across
project X, Y, and Z", which is needed when multiple projects are sharing
support/operations staff.

I guess what I'm trying to say is, if we looked at the Designate incubation
request and determined that we need to refactor the association between
identity and catalog, that would be A Good Thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130616/60716ad8/attachment.html>