<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 16, 2013 at 1:46 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 06/16/2013 10:39 AM, Mac Innes, Kiall wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 16/06/13 02:40, Monty Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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? It seems like some of the things that keystone needs to do<br>
moving forward (global registry) have been working in the DNS for, well,<br>
a long time...<br>
</blockquote>
<br>
So - I have to admit, I've not been following keystones plans very closely!<br>
<br>
I'm assuming you're taking about using DNS for discovery of<br>
regions/services/endpoints etc. Essentially replacing the service<br>
catalog? If this is what's being discussed, then absolutely. That is<br>
what SRV records were designed for.<br>
</blockquote>
<br></div>
Ah, but there's a catch. SRV records don't contain a number of pieces of information that the service catalog supplies...<br>
<br>
The service type -- is it a compute service? an identity service? a volume service? The only thing the SRV record gives you is "it's a service"... you then have to do a further query (and assume some sort of standard information discovery format) on the URI in order to determine what it is. Since all of our endpoints are TCP/IP, there is no way to use the protocol field of the SRV record to differentiate different service types. You would still need some sort of service catalog being served up from the URIs contained in the SRV record target field in order for the OpenStack clients to make sense of anything.<br>
</blockquote><div><br></div><div style>Monty's suggestion (correct me if I'm wrong) was to present a single SRV record for the cloud itself, which happens to point to the identity service. So, --os-auth-url=<a href="https://identity.api.rackspacecloud.com/v2.0">https://identity.api.rackspacecloud.com/v2.0</a> could be replaced with something more user-friendly like --os-cloud=<a href="http://rackspacecloud.com">rackspacecloud.com</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The endpoint interfaces -- unfortunately, Keystone's service catalog implementation uses a (IMHO) silly concept of admin/public/internal "interfaces" for each service endpoint. [1] There is no way to use a SRV record to indicate to clients whether a URL should be considered an admin URL, an internal URL, or a public URL. Frankly, I think the entire concept of endpoint interfaces should just be ditched in Keystone. The concept is silly. If there is a separate "admin" interface that should be physically or logically separate from some other interface, just make it a separate service... or just use RBAC like any sane service would.<br>
</blockquote><div><br></div><div style>+1; identity API v3 presents a step in exactly that direction (one endpoint has one URL, rather than up to three with arbitrary "types"). Today v3 describes the interface as required just to achieve parity with and a migration path from v2, but down the line we can relax that to be optional and assume the endpoint itself is "public" and enforcing it's own RBAC.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
We could use a TXT record to inject some data about the type of service a DNS record is, though. That way, we could write a blob of JSON into the TXT record for the target domain name that would contain some information about the service endpoints.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So - Should Keystone and Designate merge? I don't believe they should.<br>
Keystone is the OpenStack Identity service - It provides authentication<br>
and authorization services, which happens to include a list of services<br>
to which you are authorized to access.<br>
</blockquote>
<br></div>
I don't believe they should merge, as I think Designate is targeted at the tenant, not the underlying services needing a service catalog.<br>
<br>
What I think is a better idea is to write a Designate catalog driver for Keystone, that itself could call a Designate endpoint to write the afortementioned SRV and TXT records to whatever DNS backends that Designate supports.<br>

<br>
I think the entire service catalog module in Keystone should be rewritten, starting from a new object model for the objects involved in the service catalog:<br>
<br>
* Region -- this object isn't a first-class citizen in Keystone right now, and its design suffers because of it. By Region I refer to a generic area with no geographic connotation to it.<br>
* Endpoint -- A URI publishing a service of some kind<br>
* ServiceType -- the type of service available at an endpoint<br>
<br>
Once the object model is fully fleshed out, then the existing API which returns a denormalized, inflexible, unfiltered list of all endpoints in all regions, should be refactored to promote the natural regional hierarchy that DNS naturally fits.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm not sure hosting $customer's DNS is an obvious fit within that scope.<br>
</blockquote>
<br></div>
No, it definitely isn't.<br>
<br>
Best,<br>
-jay<br>
<br>
[1] <a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#endpoints-v3endpoints" target="_blank">https://github.com/openstack/<u></u>identity-api/blob/master/<u></u>openstack-identity-api/src/<u></u>markdown/identity-api-v3.md#<u></u>endpoints-v3endpoints</a><div class="">
<div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>