openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

Liem,

"I think yes, because service is just a logical concept, and endpoint API
may decide to support multiple services (for billing or whatever)..."

Can you explain this a bit further? I'm completely lost on what you're
describing.

-Dolph

On Wed, Apr 25, 2012 at 12:13 PM, Nguyen, Liem Manh <liem_m_nguyen@xxxxxx>wrote:

>
>
> From: Joseph Heck [mailto:heckj@xxxxxx]
> Sent: Wednesday, April 25, 2012 9:47 AM
> To: Nguyen, Liem Manh
> Cc: Joe Savak; openstack@xxxxxxxxxxxxxxxxxxx (
> openstack@xxxxxxxxxxxxxxxxxxx); Adam Gandelman
> Subject: Re: [Openstack] [Keystone] What exactly are we modeling with
> endpoints?
>
> This isn't about parsing the data structure - it's about what a "service"
> represents so that we can model it appropriately. So what does the
> "service" here represent? the collection of all possible services of that
> type? That's what your example would seem to indicate.
>
> In your example, the service is a pretty simple structure - just having a
> type (driven by convention and API spec) and human readable name, and each
> service is expected to have 1 to N endpoints.
>
> Is it reasonable to have a service without any endpoints? Regardless of
> reasonable, is it allowable?
>
> > Liem:  Will we ever have a service that has no endpoints?  With no way
> to contact the service, can one utilize the service?  If we answer no to
> those questions, then I think we should have service 0..* <-> 1..*
> endpoint.  Also, can an endpoint have more than 1 services?  I think yes,
> because service is just a logical concept, and endpoint API may decide to
> support multiple services (for billing or whatever)...
>
> What does an endpoint represent? The API's URI point, clearly. Is there a
> uniqueness constraint of any kind on endpoints? Is it allowable (if
> strange) to list 3 duplicate endpoints with exactly the same metadata on it?
>
> > Liem: I like the fact that we are not enforcing unique constraints on
> endpoints; so, services have the freedom to define what is needed.
>
> -joe
>
> On Apr 25, 2012, at 9:37 AM, Nguyen, Liem Manh wrote:
> I would like to keep the service type  and name under the service and not
> the endpoint, too.  Make it easier to parse for a given service.
>
> One thing is that I am not sure if we need the metadata tag. In the
> Keystone XSD, we have the construct <anyAttribute namespace="##other"
> processContents="lax"/>, which allows any additional,
> implementation-specific attribute to be added.  Those that do not support
> the specific attribute can simply ignore it.   A couple of benefits I can
> see with not using the metadata tag, and just use the custom element
> directly like this:  http://paste.openstack.org/show/13832/, which the
> anyAttribute supports, are:
>
> .         Simplier parsing, one level less.
> .         If that attribute becomes a core attribute later, no need to
> change the parser.
>
> Liem
>
> From: openstack-bounces+liem_m_nguyen=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:
> openstack-bounces+liem_m_nguyen=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Joe Savak
> Sent: Tuesday, April 24, 2012 1:04 PM
> To: Joseph Heck; openstack@xxxxxxxxxxxxxxxxxxx (
> openstack@xxxxxxxxxxxxxxxxxxx)
> Cc: Adam Gandelman
> Subject: Re: [Openstack] [Keystone] What exactly are we modeling with
> endpoints?
>
> Having endpoints under the service construct is supposed to make it easier
> to programmatically find the endpoint(s) you are interested in.
>
> For example - as nova client I can parse the service catalog and identity
> nova by service-type "compute" in order to get the public, internal, and
> admin endpoints for nova.
>
> By having service type & name as attributes under the endpoint, I'll have
> a harder time doing that (having to dive into each endpoint construct to
> identify the ones with service-type "compute").
> Maybe it would be better to have each endpoint have its own construct
> inside of a service.
>
> So instead of http://paste.openstack.org/show/13678/
> Maybe http://paste.openstack.org/show/13682/
>
>
> From: openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx[mailto:
> openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Joseph Heck
> Sent: Friday, April 20, 2012 4:16 PM
> To: openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx)
> Cc: Adam Gandelman
> Subject: [Openstack] [Keystone] What exactly are we modeling with
> endpoints?
>
> While I've been roaming about the summit and conference, I've been trying
> to figure out exactly what we're modeling with the current "service" and
> "endpoints" that are in the API today. After talking with a number of
> folks, it's getting clearer that how it's being used is very installation
> specific.
>
> I'd like to simplify this aspect of the API if at all possible, especially
> with a lot of the good ideas around describing the relationships between
> endpoints and and their installation.
>
> The use cases I'm hearing actively in use are:
>
> * (Horizon/UI/client) To indicate to a user where they can go to access
> their data
> * (Glance, Nova, Keystone client) to find the endpoint relevant to
> uploading images (current client implementations appear to assume there is
> only one image endpoint)
>
> The use case to indicate a geographic location for a datacenter or "cloud"
> is not consistent - some implementations I've learned of have that feature
> (and use "Region" for that sort of information), and others are load
> balancing a single endpoint to deploy to multiple datacenters and
> geographic regions from a single endpoint.
>
> At the summit and conference, I heard a desire to expose geographic
> information with the endpoints, but that is clearly an operator specific
> implementation/deployment detail. Likewise I heard a lot of "We could
> really..." if additional metadata was easily available on endpoints, again
> in fairly implementation/deployment specific detail.
>
> So looking forward towards a v.next API, what do you all think about
> having just "endpoints", with everything else being attributes on those
> endpoints (including what "service" and "type" it is), with some expected
> conventions (that there are a few well defined types - such as PublicURL
> and InternalURL, and relevant names for the rest API endpoints (ec2,
> compute, volume, image, identity...)
>
> Additional metadata can then float on the endpoints in
> deployment/implementation specific ways that don't lock in other systems to
> be deployed and implemented in the same fashion.
>
> -joe
>
>
> On Apr 20, 2012, at 1:47 PM, Lorin Hochstein wrote:
> On Apr 13, 2012, at 12:34 PM, Adam Gandelman wrote:
> On 04/13/2012 10:50 AM, Dolph Mathews wrote:
> While $(tenant_id)s is certainly the documented syntax, it appears that
> the SQL catalog backend (and *only* the SQL catalog backend, as far as I
> can tell) explicitly supports both $(tenant_id)s and %(tenant_id)s:
>
>
> https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L163
>
> Perhaps Adam Gandelman has some insight?
>
> -Dolph
>
> Dolph-
>
> No, the same is supported in the case of templated catalog as well, which
> is what the SQL catalog was largely based off:
>
>
> https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L115
>
> Just tested that "sed -i 's/\$/%/g'
> /etc/keystone/default_catalog.templates" still produces a functional
> service catalog when configured to use the templated backend.
>
> Seeing as both are supported, perhaps it would be better for docs to be
> updated to refer to the use of % instead of $ to avoid people running into
> problems with the $() sub-shell?
>
> The OpenStack Install and Deploy manual has some language about this (see
> last paragraph):
> http://docs.openstack.org/trunk/openstack-compute/install/content/elements-of-keystone-service-catalog-entry.html
>
> This hasn't made its way into the admin docs yet, though.
>
>
> Take care,
>
> Lorin
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>