Open Stack

On Sun, Jun 16, 2013 at 1:46 PM, Jay Pipes <jaypipes at gmail.com> wrote:

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

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=https://identity.api.rackspacecloud.com/v2.0could
be replaced with something more user-friendly like --os-cloud=
rackspacecloud.com


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

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


>
> 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<https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#endpoints-v3endpoints>
>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130616/8c89e17b/attachment.html>