openstack team mailing list archive

["Yee, Guang" <guang.yee@xxxxxx>]

A service can have 0 to N endpoints. Why not? To the end users, what's the
difference between no endpoints and unreachable endpoints anyway. It should
be up to the client to return a more human-readable, actionable error
message.

An endpoint is basically consisted of an URI and a bunch of
characteristics/attributes about that URI right? Question is which
characteristics should be core and which characteristic are
vendor/deployment-specific.

As Liem mentioned, the schema does allow vendors to add arbitrary attributes
to the endpoints with having to use meta data.


Guang


-----Original Message-----
From: openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+guang.yee=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Nguyen, Liem Manh
Sent: Wednesday, April 25, 2012 10:14 AM
To: Joseph Heck
Cc: Adam Gandelman; openstack@xxxxxxxxxxxxxxxxxxx
(openstack@xxxxxxxxxxxxxxxxxxx)
Subject: Re: [Openstack] [Keystone] What exactly are we modeling with
endpoints?



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/conten
t/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

Attachment: smime.p7s
Description: S/MIME cryptographic signature