Open Stack

On 16/06/13 22:09, Mark Washenberger wrote:
> On Sat, Jun 15, 2013 at 6:37 PM, Monty Taylor <mordred at inaugust.com
> <mailto: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.

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