openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

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 <dolph.mathews@xxxxxxxxx>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 <heckj@xxxxxx> 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 <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/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@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
>>
>>
>