Open Stack

On 16/06/13 19:50, Jay Pipes wrote:
> On 06/16/2013 10:39 AM, Mac Innes, Kiall wrote:
>> 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.

SRV records are typically well known / squatted names.

For example:

* XMPP federation: _xmpp-server._tcp.provider.com
* Kerberos KDC discovery: _kerberos._udp.company.com
* MS Active Directory site specific LDAP server: 
_ldap._tcp.$site._sites.company.com

You'll notice that last one includes the notion of "sites" similar to 
OpenStack's regions. This is an MS convention, but shows a possible 
convention for handling multiple regions..

>
> 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.

This comes back to providing the necessary conventions.. Maybe something 
along these lines:

_compute._tcp.us-west.provider.com +
_compute-admin._tcp.us-west.provider.com +
_compute-internal.tcp.us-west.provider.com

> 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.

Completely agree :)

>
> 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.

Again, I think providing (and following) well known conventions can make 
this unnecessary for the most part.


>> 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.

+1 - Assuming some conventions are agreed upon..

> 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
>