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