On 16/06/13 22:09, Mark Washenberger wrote: > On Sat, Jun 15, 2013 at 6:37 PM, Monty Taylor <[email protected] > <mailto:[email protected]>> 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.
DNS has plenty of history as a "service catalog" of sorts, with things like XMPP, Kerberos making "simple" use of DNS for discovery and MS's Active Directory making heavy use of DNS for discovery. > 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. > I hold off commenting any more on Keystone, as I'm way out of the loop on their plans :) Thanks, Kiall _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
