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_ngu...@hp.com>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 <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....@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 > 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/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp