Open Stack

On 06/16/2013 10:39 AM, Mac Innes, Kiall wrote:
> On 16/06/13 02:40, Monty Taylor wrote:
>> 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? It seems like some of the things that keystone needs to do
>> moving forward (global registry) have been working in the DNS for, well,
>> a long time...
>
> So - I have to admit, I've not been following keystones plans very closely!
>
> I'm assuming you're taking about using DNS for discovery of
> regions/services/endpoints etc. Essentially replacing the service
> catalog? If this is what's being discussed, then absolutely. That is
> what SRV records were designed for.

Ah, but there's a catch. SRV records don't contain a number of pieces of 
information that the service catalog supplies...

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.

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.

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.

> So - Should Keystone and Designate merge? I don't believe they should.
> Keystone is the OpenStack Identity service - It provides authentication
> and authorization services, which happens to include a list of services
> to which you are authorized to access.

I don't believe they should merge, as I think Designate is targeted at 
the tenant, not the underlying services needing a service catalog.

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.

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:

* 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.
* Endpoint -- A URI publishing a service of some kind
* ServiceType -- the type of service available at an endpoint

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.

> I'm not sure hosting $customer's DNS is an obvious fit within that scope.

No, it definitely isn't.

Best,
-jay

[1] 
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#endpoints-v3endpoints