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 > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
