Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Doug Hellmann]

On Fri, Apr 20, 2012 at 5:15 PM, Joseph Heck  wrote:

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

That makes a lot of sense. Justin proposed some image metadata naming
conventions at the summit. It would be nice if the vendor-specific
properties on endpoints used similar conventions.

Doug
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Joe Savak]

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@lists.launchpad.net 
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
Behalf Of Joseph Heck
Sent: Friday, April 20, 2012 4:16 PM
To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~o

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Nguyen, Liem Manh]

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 , 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@lists.launchpad.net 
[mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf 
Of Joe Savak
Sent: Tuesday, April 24, 2012 1:04 PM
To: Joseph Heck; openstack@lists.launchpad.net (openstack@lists.launchpad.net)
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@lists.launchpad.net 
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
Behalf Of Joseph Heck
Sent: Friday, April 20, 2012 4:16 PM
To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
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 i

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Joseph Heck]

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?

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?

-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  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@lists.launchpad.net 
> [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf 
> Of Joe Savak
> Sent: Tuesday, April 24, 2012 1:04 PM
> To: Joseph Heck; openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> 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@lists.launchpad.net 
> [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
> Behalf Of Joseph Heck
> Sent: Friday, April 20, 2012 4:16 PM
> To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> 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 w

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Dolph Mathews]

+1 for skipping the "metadata" container; seems superfluous.

The service type (compute, identity, etc) should definitely be distinct from 
the endpoint's type (public, admin, internal, etc). The endpoint type should 
also be more easily flexible than it is today -- we've had complaints about 
hard coding the three existing types (which is quite ugly, IMO), and not 
providing simple support for additional types (e.g. read-only feed endpoints).

The endpoint versioning attributes seem to confuse everyone as well (I'm not 
even sure I understand it myself), so there's certainly room for improvement 
there as well.

-Dolph Mathews

On Apr 25, 2012, at 11: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  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@lists.launchpad.net 
> [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf 
> Of Joe Savak
> Sent: Tuesday, April 24, 2012 1:04 PM
> To: Joseph Heck; openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> 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@lists.launchpad.net 
> [mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
> Behalf Of Joseph Heck
> Sent: Friday, April 20, 2012 4:16 PM
> To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> 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

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Nguyen, Liem Manh]

From: Joseph Heck [mailto:he...@me.com] 
Sent: Wednesday, April 25, 2012 9:47 AM
To: Nguyen, Liem Manh
Cc: Joe Savak; openstack@lists.launchpad.net (openstack@lists.launchpad.net); 
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 , 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@lists.launchpad.net 
[mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf 
Of Joe Savak
Sent: Tuesday, April 24, 2012 1:04 PM
To: Joseph Heck; openstack@lists.launchpad.net (openstack@lists.launchpad.net)
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@lists.launchpad.net 
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
Behalf Of Joseph Heck
Sent: Friday, April 20, 2012 4:16 PM
To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
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&

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Andy Smith]

How about let's rephrase this question:

Who is actually explicitly using the service catalog (besides just having
keystoneclient find the next auth endpoint)? What complaints do you have?

AKA, trying to pull some data out of it and use it to in some way
"discover" a service.

>From my experiences, it appears Nova uses it to find out where Glance is,
and Horizon uses it to find out where Nova and Glance are.

--andy


On Wed, 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  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@lists.launchpad.net[mailto:
> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf Of
> *Joe Savak
> *Sent:* Tuesday, April 24, 2012 1:04 PM
> *To:* Joseph Heck; openstack@lists.launchpad.net (
> openstack@lists.launchpad.net)
> *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@lists.launchpad.net[mailto:
> openstack-bounces+joe.savak=rackspace@lists.launchpad.net] *On Behalf
> Of *Joseph Heck
> *Sent:* Friday, April 20, 2012 4:16 PM
> *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> *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

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Joe Savak]

Is it reasonable to have a service without any endpoints?

There are no use cases today that I know of that would need a service 
represented in the service catalog without endpoints. Since the future is vague 
though and each implementation could be different, I don't think we should 
require a service to have an endpoint.

Same with 3 duplicate endpoints - a use case could come up and the core 
contract should be flexible enough with these things.

From: Joseph Heck [mailto:he...@me.com]
Sent: Wednesday, April 25, 2012 11:47 AM
To: Nguyen, Liem Manh
Cc: Joe Savak; openstack@lists.launchpad.net (openstack@lists.launchpad.net); 
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?

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?

-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 , 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@lists.launchpad.net<mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net>
 
[mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net<mailto:hp@lists.launchpad.net>]
 On Behalf Of Joe Savak
Sent: Tuesday, April 24, 2012 1:04 PM
To: Joseph Heck; 
openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 
(openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>)
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@lists.launchpad.net<mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net>
 
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net<mailto:rackspace@lists.launchpad.net>]
 On Behalf Of Joseph Heck
Sent: Friday, April 20, 2012 4:16 PM
To: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 
(openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>)
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 fi

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Dolph Mathews]

I'm not sure it makes sense for a "service" to have more than one
"endpoint." Two different endpoints might as well be two separate services
IMO, even if they directly affect each other.

For example, creating a tenant on the identity admin endpoint makes that
tenant just as available on the identity public endpoint as it does on the
compute public endpoint, but of course it doesn't make sense to say all of
nova is suddenly part of keystone.

There are (at least) two attributes that must be provided to distinguish
between two endpoints: the API "type" and the endpoint/url "type." ("admin
+ identity" vs "public + compute" vs "internal + volumes"). Trying to group
endpoints at a high level by API type alone strikes me as very arbitrary,
at best.

If I'm going to "collect" anything, it would be which endpoints work (or
work *best*) with which *other* endpoints. See:
https://blueprints.launchpad.net/keystone/+spec/service-relationships

-Dolph

On Wed, Apr 25, 2012 at 11:47 AM, Joseph Heck  wrote:

> 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?
>
> 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?
>
> -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  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@lists.launchpad.net[mailto:
> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf Of
> *Joe Savak
> *Sent:* Tuesday, April 24, 2012 1:04 PM
> *To:* Joseph Heck; openstack@lists.launchpad.net (
> openstack@lists.launchpad.net)
> *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@lists.launchpad.net[mailto:
> openstack-bounces+joe.savak=rackspace@lists.launchpad.net] *On Behalf
> Of *Joseph Heck
> *Sent:* Friday, April 20, 2012 4:16 PM
> *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> *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 c

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Nguyen, Liem Manh]

A common use-case for a "service" to have more than one "endpoints" is when 
there are different regions for different endpoints serving the same service.  
This is potentially a place where the endpoints may be discriminated, if the 
consumer of the catalogue is "geo"-aware.

Liem

From: anti...@gmail.com [mailto:anti...@gmail.com] On Behalf Of Dolph Mathews
Sent: Wednesday, April 25, 2012 11:00 AM
To: Joseph Heck
Cc: Nguyen, Liem Manh; Adam Gandelman; openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

I'm not sure it makes sense for a "service" to have more than one "endpoint." 
Two different endpoints might as well be two separate services IMO, even if 
they directly affect each other.

For example, creating a tenant on the identity admin endpoint makes that tenant 
just as available on the identity public endpoint as it does on the compute 
public endpoint, but of course it doesn't make sense to say all of nova is 
suddenly part of keystone.

There are (at least) two attributes that must be provided to distinguish 
between two endpoints: the API "type" and the endpoint/url "type." ("admin + 
identity" vs "public + compute" vs "internal + volumes"). Trying to group 
endpoints at a high level by API type alone strikes me as very arbitrary, at 
best.

If I'm going to "collect" anything, it would be which endpoints work (or work 
*best*) with which *other* endpoints. See: 
https://blueprints.launchpad.net/keystone/+spec/service-relationships

-Dolph

On Wed, Apr 25, 2012 at 11:47 AM, Joseph Heck 
mailto:he...@me.com>> wrote:
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?

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?

-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 , 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@lists.launchpad.net<mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net>
 
[mailto:openstack-bounces+liem_m_nguyen<mailto:openstack-bounces%2Bliem_m_nguyen>=hp@lists.launchpad.net<mailto:hp@lists.launchpad.net>]
 On Behalf Of Joe Savak
Sent: Tuesday, April 24, 2012 1:04 PM
To: Joseph Heck; 
openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 
(openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>)
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@lists.launchpad.net<mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net>
 
[mailto:openstack-bounces+joe.savak<mailto:openstack-bounc

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Yee, Guang]

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@lists.launchpad.net
[mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of
Nguyen, Liem Manh
Sent: Wednesday, April 25, 2012 10:14 AM
To: Joseph Heck
Cc: Adam Gandelman; openstack@lists.launchpad.net
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Keystone] What exactly are we modeling with
endpoints?



From: Joseph Heck [mailto:he...@me.com] 
Sent: Wednesday, April 25, 2012 9:47 AM
To: Nguyen, Liem Manh
Cc: Joe Savak; openstack@lists.launchpad.net
(openstack@lists.launchpad.net); 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 , 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@lists.launchpad.net
[mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On
Behalf Of Joe Savak
Sent: Tuesday, April 24, 2012 1:04 PM
To: Joseph Heck; openstack@lists.launchpad.net
(openstack@lists.launchpad.net)
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@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of Joseph Heck
Sent: Friday, April 20, 2012 4:16 PM
To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
Cc: Adam Gandelman
Subject: [Openstack] [Keystone] What exactly are we modeling with endpoints?
 
While I've been roaming about the summit and confe

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Dolph Mathews]

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

>
>
> From: Joseph Heck [mailto:he...@me.com]
> Sent: Wednesday, April 25, 2012 9:47 AM
> To: Nguyen, Liem Manh
> Cc: Joe Savak; openstack@lists.launchpad.net (
> openstack@lists.launchpad.net); 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  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@lists.launchpad.net [mailto:
> openstack-bounces+liem_m_nguyen=hp....@lists.launchpad.net] On Behalf
> Of Joe Savak
> Sent: Tuesday, April 24, 2012 1:04 PM
> To: Joseph Heck; openstack@lists.launchpad.net (
> openstack@lists.launchpad.net)
> 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@lists.launchpad.net[mailto:
> openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On Behalf
> Of Joseph Heck
> Sent: Friday, April 20, 2012 4:16 PM
> To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> 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

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Nguyen, Liem Manh]

For example, block storage and compute go hand-in-hand in Openstack...  But, 
what if someone wants to separate them for billing purpose for instance, then 
those would become separate services, but the endpoint may be the same...  We 
could require the endpoints in this case to be different, but, I think we 
should not impose that on the service provider to give them as much freedom as 
possible in terms of implementation... After all, service and endpoints are 
their realm :).

Liem

From: anti...@gmail.com [mailto:anti...@gmail.com] On Behalf Of Dolph Mathews
Sent: Wednesday, April 25, 2012 12:02 PM
To: Nguyen, Liem Manh
Cc: Joseph Heck; Adam Gandelman; openstack@lists.launchpad.net 
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

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 
mailto:liem_m_ngu...@hp.com>> wrote:


From: Joseph Heck [mailto:he...@me.com<mailto:he...@me.com>]
Sent: Wednesday, April 25, 2012 9:47 AM
To: Nguyen, Liem Manh
Cc: Joe Savak; 
openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 
(openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>); 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 , 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@lists.launchpad.net<mailto:hp@lists.launchpad.net>
 
[mailto:openstack-bounces+liem_m_nguyen<mailto:openstack-bounces%2Bliem_m_nguyen>=hp@lists.launchpad.net<mailto:hp@lists.launchpad.net>]
 On Behalf Of Joe Savak
Sent: Tuesday, April 24, 2012 1:04 PM
To: Joseph Heck; 
openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 
(openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>)
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 endpoi

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Dolph Mathews]

On another note: Regions.

I acknowledge that there's a real-world problem to be solved here, but A)
no two deployments seem to share the same philosophy on how to describe the
problem or it's complexity, B) some deployments don't have that problem at
all (e.g. devstack).

The concept of a "region" is totally arbitrary and meaningless to a large
majority of users, and our documentation / default values very much reflect
that reality, e.g. values of "RegionOne" (arbitrary and meaningless) &
"North" (totally arbitrary).

Whatever the "correct" solution is, it needs to be just as generic,
flexible and optional as the problem domain being addressed.

Skimming through the current state of
http://wiki.openstack.org/KeystoneUseCases , use cases for "regions" (and
related features) appear to be missing (correct me if I'm wrong). Please,
contribute yours!

-Dolph

On Wed, Apr 25, 2012 at 1:00 PM, Dolph Mathews wrote:

> I'm not sure it makes sense for a "service" to have more than one
> "endpoint." Two different endpoints might as well be two separate services
> IMO, even if they directly affect each other.
>
> For example, creating a tenant on the identity admin endpoint makes that
> tenant just as available on the identity public endpoint as it does on the
> compute public endpoint, but of course it doesn't make sense to say all of
> nova is suddenly part of keystone.
>
> There are (at least) two attributes that must be provided to distinguish
> between two endpoints: the API "type" and the endpoint/url "type." ("admin
> + identity" vs "public + compute" vs "internal + volumes"). Trying to group
> endpoints at a high level by API type alone strikes me as very arbitrary,
> at best.
>
> If I'm going to "collect" anything, it would be which endpoints work (or
> work *best*) with which *other* endpoints. See:
> https://blueprints.launchpad.net/keystone/+spec/service-relationships
>
> -Dolph
>
> On Wed, Apr 25, 2012 at 11:47 AM, Joseph Heck  wrote:
>
>> 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?
>>
>> 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?
>>
>> -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 > 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@lists.launchpad.net[mailto:
>> openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] *On Behalf Of
>>  *Joe Savak
>> *Sent:* Tuesday, April 24, 2012 1:04 PM
>> *To:* Joseph Heck; openstack@lists.launchpad.net (
>> openstack@lists.launchpad.net)
>> *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 id

Re: [Openstack] [Keystone] What exactly are we modeling with endpoints?

[Dolph Mathews]

Yee,

What are you modeling by saying you can have a service without an endpoint?
What's a service without a means of serving?

-Dolph

On Wed, Apr 25, 2012 at 1:54 PM, Yee, Guang  wrote:

> 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@lists.launchpad.net
> [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf
> Of
> Nguyen, Liem Manh
> Sent: Wednesday, April 25, 2012 10:14 AM
> To: Joseph Heck
> Cc: Adam Gandelman; openstack@lists.launchpad.net
> (openstack@lists.launchpad.net)
> Subject: Re: [Openstack] [Keystone] What exactly are we modeling with
> endpoints?
>
>
>
> From: Joseph Heck [mailto:he...@me.com]
> Sent: Wednesday, April 25, 2012 9:47 AM
> To: Nguyen, Liem Manh
> Cc: Joe Savak; openstack@lists.launchpad.net
> (openstack@lists.launchpad.net); 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  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@lists.launchpad.net
> [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On
> Behalf Of Joe Savak
> Sent: Tuesday, April 24, 2012 1:04 PM
> To: Joseph Heck; openstack@lists.launchpad.net
> (openstack@lists.launchpad.net)
> 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
> ha