openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

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 <guang.yee@xxxxxx> 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.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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>