<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 15, 2013 at 6:37 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 06/10/2013 10:49 AM, Mac Innes, Kiall wrote:<br>
><br>
> Some interesting use cases are service discovery[1], replacing the<br>
> traditional model of trust in browsers for HTTPS[2], authenticating<br>
> email with DKIM[3], establishing SSH host key trust[4], aiding in the<br>
> prevention of spam[5].. and many many more. Not all these examples are<br>
> practical today, but they do provide examples of DNS functions which are<br>
> outside the scope of OpenStack Networking.<br>
<br>
</div>SO - As a huge supporter of using dns for things (since it's the world's<br>
most scalable database), can I turn this around a little bit?<br>
<br>
Why don't we use DNS and/or a DNSaaS implementation to do the things in<br>
the list that are above that are currently keystone's job in openstack?<br>
Or, stated differently, why isn't this part of keystone, or keystone<br>
part of this?</blockquote><div><br></div><div><br></div><div style>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.</div>
<div style><br></div><div style>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:</div>
<div style>   - 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</div><div style>   - service catalog views are always restricted to a specific project, since a token is in general valid only for a specific project</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div><br></div></div></div></div>