[Openstack] python-keystoneclient v0.3.0 released

[Dolph Mathews]

python-keystoneclient v0.3.0 has been released to pypi [1].

Bug fixes [2] since v0.2.5 include two security vulnerabilities [3]
[4] related to keystoneclient.middleware.auth_token's handling of signing &
encryption for memcache.

This release also includes support for Identity API v3 [5] auth and
identity management through the Python API. Identity API v3 support will be
exposed on the CLI through the python-openstackclient project [6].

[1]: https://pypi.python.org/pypi/python-keystoneclient/
[2]: https://bugs.launchpad.net/python-keystoneclient/+milestone/0.3.0
[3]: https://bugs.launchpad.net/bugs/1175367
[4]: https://bugs.launchpad.net/bugs/1175368
[5]:
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md
[6]: https://launchpad.net/python-openstackclient/

-Dolph
___
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] OpenStack API versions and release content

[Dolph Mathews]

On Tue, Jun 11, 2013 at 4:46 PM, Farhan Patwa  wrote:

>  Hi all,
> I am just trying to understand the motivation behind creations API
> versions and how that ties in to a release content.
> As per listed documentation (
> http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html
> )
> "New Features and functionality that break  API-compatibility necessitate
> a new version. When new API version are released older versions are marked
> as deprecated."
>
>  My questions are:
> 1.) Is the assumption here that operators may update the release but opt
> to stay with an older API version to get bug fixes etc.?
>

See #2 below.


> 2.) Do new versions have to be deployed with a new release? Keystone has
> V3 version, but I don't see it being available for use in devstack or
> Grizzly release (based on my assumption that the command 'keystone
> discover' will display supported API versions)
>

Not necessarily. Keystone grizzly/2013.1 ships with a revised paste
configuration which deploys the new Identity API v3 via pipeline:api_v3
[1]. You don't need to deploy this new pipeline at all, and a folsom paste
configuration will deploy an Identity API v2 implementation just as it did
in folsom. The output of "keystone discover" operates based on how the
service catalog is populated, which doesn't necessarily reflect the
configured pipeline or what's provided by the implementation.

[1]:
https://github.com/openstack/keystone/blob/64738924b87e6fb31d999e25da23f889a2658940/etc/keystone-paste.ini#L78


> 3.) Do versions have their own release schedule (so Keystone V3 is part of
> Grizzly code but the implementation is not yet complete or supported??)
>

There's no such thing as "Keystone v3," although that's a common misnomer.
The Identity API (v2.0 -> v3.0 -> v3.1) is versioned independently from
it's implementation, Keystone (... essex/2012.1 -> folsom/2012.2 ->
grizzly/2013.1 -> etc). Several releases of keystone could be made without
incrementing the API version. A release of keystone may contain an
experimental/unstable/partial and unrecommended/undocumented implementation
of a newer API. A release of keystone may even skip an API version if there
was reason to do so.

So, for example:

- diablo supports Identity API v2.0 and was extensible to support a
non-OpenStack Identity API (v1.1)
- essex supports Identity API v2.0
- folsom supports Identity API v2.0
- grizzly supports Identity API v2.0 and Identity API v3.0
- havana will support Identity API v2.0 and Identity API v3.1
- icehouse will support Identity API v2.0 and at least Identity API v3.1
(if not v3.2)
- J*release is not guaranteed to support Identity API v2.0 and will support
at least Identity API v3.1 (if not v3.3)

(where minor version bumps, e.g. v3.0 -> v3.1 are backwards compatible)

In reality, if we ship a recommended API implementation, that API version
is effectively feature frozen. So, while we could have continued to develop
Identity API v3.0 past 2013.1, we documented it in the default
configuration (keystone.conf.sample, devstack, etc) and shipped it with
grizzly and are now working towards introducing backwards-compatible
features under a minor version bump to the API that will ship with havana.


>
>  I would really appreciate if someone can shed light on this.
>
>  Thanks for your time,
>
>  -Farhan Patwa.
>
> ___
> 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

Re: [Openstack] python-keystoneclient 0.2.4 available on pypi

[Dolph Mathews]

Just a small update... the --version flag was broken in 0.2.4 [1], so 0.2.5
has now been released to pypi [2] specifically to fix this issue.

[1]: https://launchpad.net/python-keystoneclient/+milestone/0.2.5
[2]: https://pypi.python.org/pypi/python-keystoneclient/

-Dolph


On Wed, May 29, 2013 at 12:33 PM, Dolph Mathews wrote:

> python-keystoneclient 0.2.4 is primarily a security & bug fix release [1]
> and is now available on pypi [2].
>
> A few highlights concerning the auth_token middleware:
>
> - Expired PKI tokens are now rejected [3]
> - PKI token revocations lists are now cached using a configurable
> expiration (revocation_cache_time) [4]
> - The signing_dir configuration option now defaults to a secure, temporary
> directory rather than the user's home directory [5]
>
> Additionally, updating a user's password on the CLI can now be done
> securely [6].
>
> [1]: https://launchpad.net/python-keystoneclient/+milestone/0.2.4
> [2]: https://pypi.python.org/pypi/python-keystoneclient
> [3]: https://bugs.launchpad.net/python-keystoneclient/+bug/1179615
> [4]: https://bugs.launchpad.net/python-keystoneclient/+bug/1076083
> [5]: https://bugs.launchpad.net/python-keystoneclient/+bug/1181157
> [6]: https://bugs.launchpad.net/python-keystoneclient/+bug/938315
>
> -Dolph
>
___
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 8K header size limit

[Dolph Mathews]

Apologies, none of these configuration settings were documented in
etc/keystone.conf.sample. The last one is the one that controls this
behavior.

  [DEFAULT]

  # enforced by sizelimit middleware
(keystone.middleware:RequestBodySizeLimiter)
  max_request_body_size = 114688

  # limit the sizes of user & tenant ID/names
  max_param_size = 64

  # similar to max_param_size, but provides an exception for token values
  max_token_size = 8192

I also put these docs up for review: https://review.openstack.org/30932



-Dolph


On Wed, May 29, 2013 at 1:23 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hi Guang,
>
> We are running into a problem with PKI tokens being greater than 8K and
> having Keystone not able to validate them. Do you know of a workaround?
>
> Mark
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

[Openstack] python-keystoneclient 0.2.4 available on pypi

[Dolph Mathews]

python-keystoneclient 0.2.4 is primarily a security & bug fix release [1]
and is now available on pypi [2].

A few highlights concerning the auth_token middleware:

- Expired PKI tokens are now rejected [3]
- PKI token revocations lists are now cached using a configurable
expiration (revocation_cache_time) [4]
- The signing_dir configuration option now defaults to a secure, temporary
directory rather than the user's home directory [5]

Additionally, updating a user's password on the CLI can now be done
securely [6].

[1]: https://launchpad.net/python-keystoneclient/+milestone/0.2.4
[2]: https://pypi.python.org/pypi/python-keystoneclient
[3]: https://bugs.launchpad.net/python-keystoneclient/+bug/1179615
[4]: https://bugs.launchpad.net/python-keystoneclient/+bug/1076083
[5]: https://bugs.launchpad.net/python-keystoneclient/+bug/1181157
[6]: https://bugs.launchpad.net/python-keystoneclient/+bug/938315

-Dolph
___
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

[Dolph Mathews]

The "SERVICE_TOKEN" is not a password; it should either be a valid token
that you've generated using credentials + keystone token-get, or the value
of keystone.conf's static admin_token option. I'm not familiar with x.sh so
I don't know if you should remove SERVICE_* env vars or the OS_* ones, but
having both sets is redundant.


-Dolph


On Tue, May 14, 2013 at 7:43 AM, Mahzad Zahedi wrote:

> I have followed basic install guide openstack on ubuntu  (grizzy) so
> for configuration keystone first,
>
> I have created openrc File and added below lines into it:
>
> export OS_TENANT_NAME=admin
> export OS_USERNAME=admin
> export OS_PASSWORD=password
> export OS_AUTH_URL="http://localhost:5000/v2.0/";
> export SERVICE_ENDPOINT="http://localhost:35357/v2.0";
> export SERVICE_TOKEN=password
>
> and then  again I have created a x.sh file for script that is
> mentioned inside of install doc
>
> #!/bin/bash
> # Modify these variables as needed
> ADMIN_PASSWORD=${ADMIN_PASSWORD:-password}
>
>
> NOW , when running ./x.sh i have belo errors:
>
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 36: 2: command not found
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 38: 2: command not found
> Invalid OpenStack Identity credentials.
> Invalid OpenStack Identity credentials.
> Invalid OpenStack Identity credentials.
> usage: keystone user-create --name  [--tenant-id ]
> [--pass ] [--email ]
> [--enabled ]
> keystone user-create: error: argument --tenant-id: expected one argument
> ./bash_script.sh: line 45: 2: command not found
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 48: --tenant-id: command not found
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 51: password: command not found
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 54: --tenant-id: command not found
> Invalid OpenStack Identity credentials.
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 58: 2: command not found
> usage: keystone user-role-add --user  --role  [--tenant
> ]
> keystone user-role-add: error: argument --user/--user-id/--user_id:
> expected one argument
> usage: keystone user-role-add --user  --role  [--tenant
> ]
> keystone user-role-add: error: argument --tenant/--tenant-id: expected
> one argument
> usage: keystone user-role-add --user  --role  [--tenant
> ]
> keystone user-role-add: error: argument --tenant/--tenant-id: expected
> one argument
> usage: keystone user-role-add --user  --role  [--tenant
> ]
> keystone user-role-add: error: argument --tenant/--tenant-id: expected
> one argument
> ./bash_script.sh: line 63: --role-id: command not found
> usage: keystone user-role-add --user  --role  [--tenant
> ]
> keystone user-role-add: error: argument --tenant/--tenant-id: expected
> one argument
> usage: keystone user-role-add --user  --role  [--tenant
> ]
> keystone user-role-add: error: argument --tenant/--tenant-id: expected
> one argument
> Invalid OpenStack Identity credentials.
> Invalid OpenStack Identity credentials.
> Invalid OpenStack Identity credentials.
> Invalid OpenStack Identity credentials.
> ./bash_script.sh: line 72: --description: command not found
> usage: keystone service-create --name  --type 
>[--description ]
> keystone service-create: error: argument --description: expected one
> argument
> ./bash_script.sh: line 74: OpenStack EC2 service: command not found
> Invalid OpenStack Identity credentials.
> usage: keystone endpoint-create [--region ] --service-id
>  [--publicurl ]
> [--adminurl ]
> [--internalurl ]
> keystone endpoint-create: error: argument --service-id/--service_id:
> expected one argument
> ./bash_script.sh: line 77: --publicurl: command not found
> ./bash_script.sh: line 79: --internalurl: command not found
> usage: keystone endpoint-create [--region ] --service-id
>  [--publicurl ]
> [--adminurl ]
> [--internalurl ]
> keystone endpoint-create: error: argument --service-id/--service_id:
> expected one argument
> ./bash_script.sh: line 81: --publicurl: command not found
> ./bash_script.sh: line 83: --internalurl: command not found
> usage: keystone endpoint-create [--region ] --service-id
>  [--publicurl ]
> [--adminurl ]
> [--internalurl ]
> keystone endpoint-create: error: argument --service-id/--service_id:
> expected one argument
> ./bash_script.sh: line 85: --publicurl: command not found
> usage: keystone endpoint-create [--region ] --service-id
>  [--publicurl ]
> [--adminurl ]
> [--internalurl ]
> keystone endpoint-creat

Re: [Openstack] Cinder "ERROR: Malformed request url (HTTP 400)" again

[Dolph Mathews]

It looks like cinderclient is authenticating successfully with keystone,
and something unexpected is happening at the cinder endpoint.

I'd suggest trying to replay cinderclient's request using something like
curl to perhaps provide more insight into what's actually going on.

# curl
http://10.2.232.6:8776/v1/c625d5b2b9e24f72acb2d298682ab002/volumes/detail-H
'x-auth-token:515e478eca244282a1617e43a8881c0b' --verbose

You may need a fresh x-auth-token, but the one above is from your
copy/paste and may still be valid (if not, use $ keystone token-get)


-Dolph


On Wed, May 8, 2013 at 5:52 PM, Erick Turnquist wrote:

> List,
>
> I'm a new OpenStack user who has become exceptionally frustrated trying
> to get Cinder running. I initially installed nova-volume, which appeared
> to work, and then followed the instructions on
> https://wiki.openstack.org/wiki/MigrateToCinder to migrate. Here is
> where I am stuck: seemingly every call I make against Cinder's API
> results in an HTTP 400. Here's an example call:
>
> # cinder --debug list
> connect: (192.168.128.6, 5000) 
> send: 'POST /v2.0/tokens HTTP/1.1\r\nHost:
> 192.168.128.6:5000\r\nContent-Length: 100\r\ncontent-type:
> application/json\r\naccept-encoding: gzip, deflate\r\naccept:
> application/json\r\nuser-agent: python-cinderclient\r\n\r\n'
> send: '{"auth": {"tenantName": "admin", "passwordCredentials":
> {"username": "admin", "password": "admin"}}}'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Vary: X-Auth-Token
> header: Content-Type: application/json
> header: Content-Length: 2687
> header: Date: Wed, 08 May 2013 22:42:27 GMT
> connect: (10.2.232.6, 8776) 
> send: u'GET /v1/c625d5b2b9e24f72acb2d298682ab002/volumes/detail
> HTTP/1.1\r\nHost: 10.2.232.6:8776\r\nx-auth-project-id:
> admin\r\nx-auth-token:
> 515e478eca244282a1617e43a8881c0b\r\naccept-encoding: gzip,
> deflate\r\naccept: application/json\r\nuser-agent:
> python-cinderclient\r\n\r\n'
> reply: 'HTTP/1.1 400 Bad Request\r\n'
> header: Content-Length: 65
> header: Content-Type: application/json; charset=UTF-8
> header: X-Compute-Request-Id: req-7e360dc5-8f54-477f-833c-e0ab0d20aef6
> header: Date: Wed, 08 May 2013 22:42:27 GMT
> DEBUG (shell:473) Malformed request url (HTTP 400) (Request-ID:
> req-7e360dc5-8f54-477f-833c-e0ab0d20aef6)
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/cinderclient/shell.py", line
> 470, in main
> OpenStackCinderShell().main(sys.argv[1:])
>   File "/usr/lib/python2.6/site-packages/cinderclient/shell.py", line
> 421, in main
> args.func(self.cs, args)
>   File "/usr/lib/python2.6/site-packages/cinderclient/v1/shell.py", line
> 139, in do_list
> volumes = cs.volumes.list(search_opts=search_opts)
>   File "/usr/lib/python2.6/site-packages/cinderclient/v1/volumes.py",
> line 171, in list
> "volumes")
>   File "/usr/lib/python2.6/site-packages/cinderclient/base.py", line 63,
> in _list
> resp, body = self.api.client.get(url)
>   File "/usr/lib/python2.6/site-packages/cinderclient/client.py", line
> 138, in get
> return self._cs_request(url, 'GET', **kwargs)
>   File "/usr/lib/python2.6/site-packages/cinderclient/client.py", line
> 126, in _cs_request
> **kwargs)
>   File "/usr/lib/python2.6/site-packages/cinderclient/client.py", line
> 109, in request
> raise exceptions.from_response(resp, body)
> BadRequest: Malformed request url (HTTP 400) (Request-ID:
> req-7e360dc5-8f54-477f-833c-e0ab0d20aef6)
> ERROR: Malformed request url (HTTP 400) (Request-ID:
> req-7e360dc5-8f54-477f-833c-e0ab0d20aef6)
>
> Nothing at all shows up in the Cinder API logs when I make this call,
> even with the --debug option to cinder-api. After many hours Googling
> the problem, it would seem that the it's either a malformed endpoint URL
> or missing auth_strategy, but neither of these are the case:
>
> # keystone endpoint-list
>
> +--+---+--+-++--+
> |id|   region  |
> publicurl   |   internalurl
>   |  adminurl  |
> service_id|
>
> +--+---+--+-++--+
> | 6c2d093802744c0398bbd62dc5fbc070 | RegionOne |
> http://10.2.232.6:8773/services/Cloud |
> http://192.168.128.6:8773/services/Cloud|
> http://192.168.128.6:8773/services/Admin  |
> d4ab7bb8490385bfb5457311b88c |
> | 8900b9d947d24ec280b67abb8c67b4d1 | RegionOne |
> http://10.2.232.6:8774/v2/%(tenant_id)s|
> http://192.168.128.6:8774/v2/%(tenant_id)s   |
> http://192.168.128.6:8774/v2/%(tenant_id)s |
> bb2a06fefa224e5c898eaeed41295c

Re: [Openstack] glance client not working

[Dolph Mathews]

You can't bypass authentication with, say, keystone.conf admin_token and
get a catalog. A catalog is produced as the result of authentication. Run
the client with a set of credentials (user, password, tenant, auth URL) and
you'll be able to get a catalog, and glanceclient will probably work as
well.


-Dolph


On Thu, May 2, 2013 at 7:51 AM, Dennis Jacobfeuerborn  wrote:

> On 01.05.2013 20:34, Jay Pipes wrote:
>
>> On 05/01/2013 02:28 PM, Dennis Jacobfeuerborn wrote:
>>
>>> Hi,
>>> I'm currently working on setting up OpenStack using Ansible (after
>>> giving up on Puppet) and have keystone running and Glance running.
>>> The problem I now have is that the client doesn't seem to work:
>>>
>>> [root@controller1 ~]# glance index
>>> ID   Name   Disk
>>> Format  Container Format Size
>>> --**-- --
>>>   --
>>> 'NoneType' object has no attribute 'rfind'
>>> [root@controller1 ~]# glance image-list
>>> 'NoneType' object has no attribute 'rfind'
>>> [root@controller1 ~]# glance image-create --name=cirros-0.3-x86_64
>>> --is-public=true --container-format=bare --disk-format=qcow2 <
>>> cirros-0.3.0-x86_64-disk.img
>>> 'NoneType' object has no attribute 'rfind'
>>>
>>> Unfortunately I don't get any meaningful error and the api and registry
>>> logs don't show anything either despite debug=True.
>>>
>>> Any ideas how I could find out what the problem is?
>>>
>>
>> The problem is likely your image endpoint in the Keystone service catalog.
>>
>
> Ineed the endpoint variables in the ansible template weren't substituted
> due to a typo and after fixing this I no longer get the error and
> image-list and image-create now work as expected. Thanks!
>
>
>  What does `keystone service-catalog` show?
>>
>
> There is only a 'catalog' command and that throws an error:
>
> [root@controller1 ~]# keystone catalog
> WARNING: Bypassing authentication using a token & endpoint (authentication
> credentials are being ignored).
> Configuration error: Client configured to run without a service catalog.
> Run the client using --os-auth-url or OS_AUTH_URL, instead of --os-endpoint
> or OS_SERVICE_ENDPOINT, for example.
>
> This is strange though because commands like "service-list" and
> "endpoint-list" work without any problem.
> Any idea what is special about 'catalog' to show this behaviour?
>
> Regards,
>   Dennis
>
>
> __**_
> 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

Re: [Openstack] keystone network endpoint doesnt start

[Dolph Mathews]

I imagine that you need to start quantum by running *quantum-server*


-Dolph


On Wed, May 1, 2013 at 10:18 AM, Molnár Mihály László wrote:

> hi all!
>
> I just installed Grizzly following this:
>
> https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst
> I wanted to create tenant network when I got this error:
> quantum net-create --tenant-id 1f9305114a554a89b02e5fcc786f8175 net_blabla
> [Errno 111] Connection refused
>
> So I started investigation and as I can see keystone network endpoint
> doesn't listen anywhere
> netstat output: http://pastebin.com/p44SjK2R
> keystone endpoint-list output: http://pastebin.com/a7ZFn8cX
>
> As I can see, the network endpoint in keystone database exists but
> doesnt start up. There is no error in keystone log file, or anywhere.
> I tried reboot, but for now I'm out of idea.
>
> Anybody?
>
> Thanks!
> Rusty
>
> ___
> 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

Re: [Openstack] Keystone JSON format access control policy

[Dolph Mathews]

The JSON approach is rather arbitrary; keystone has an API to manage &
publish policy blobs of any format (/v3/policies), and the policy engines
themselves are completely pluggable. I don't think there's anything
preventing a deployment from implementing an XACML based policy solution
(if there is a blocker to using XACML, it's certainly a bug).


-Dolph


On Mon, Apr 29, 2013 at 4:50 AM, Xiangjun Qian wrote:

> Hi everyone,
>
> I'm currently looking at access control mechanisms of OpenStack and
> finding that the access control policy is specified using JSON format.
>
> I'm wondering why we do not adopt an XML based approach like XACML, is it
> because of the performance problem, or we just choose JSON as it's simple?
>
> Thank you very much for your feedback.
>
> Best Regards,
>
> --
> Xiangjun
>
> ___
> 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

Re: [Openstack] Keystone Grizzly install

[Dolph Mathews]

What happens when you run keystone-all directly?


-Dolph


On Wed, Apr 24, 2013 at 4:23 PM, Viktor Viking
wrote:

> Community,
>
> I am trying to install Keystone Grizzly following these instructions:
> http://docs.openstack.org/trunk/openstack-compute/install/yum/content/install-keystone.html
>
> When I try to start the service (before db sync), I get the following
> error message: "Starting keytonestartproc: exit status of parent of
> /usr/bin/keystone-all  1 failed".
>
> /var/log/keystone/keystone.log is not giving me any clue wrt what is wrong.
>
> Could anyone let me know where to look?
> Viktor
>
> ___
> 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

Re: [Openstack] Keystone Identity based notifications

[Dolph Mathews]

Yes, we've had a few small conversations about it at the summit (don't have
an actual session scheduled on the issue, though, nor any registered
blueprints). It would be my preferred approach to resolve bugs like this
one, which is one of our longest standing and highest priority issues.

  https://bugs.launchpad.net/keystone/+bug/967832

I'd be eager to hear broader feedback on the issue.


-Dolph


On Wed, Apr 17, 2013 at 4:16 AM, boden  wrote:

> All,
> From an upper level management stack perspective, has anyone else seen the
> need for AMQP based notifications from Keystone identity and/or heard of
> any activity in this space?
>
> For example, similar to nova's notification system (
> https://wiki.openstack.org/**wiki/SystemUsageDatabased
>  on
> https://wiki.openstack.org/**wiki/NotificationSystem),
> but for events such as user/role/project/domain CRUD?
>
> I've come across this requirement a few times now, but have not turned up
> any hits via google-foo.
>
> Thanks
>
>
> __**_
> 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

Re: [Openstack] Keystone Woes

[Dolph Mathews]

Short answer: yes.

There are two types of token_format options available, PKI and UUID.

UUID tokens result in increased network chatter as they must be validated
remotely, whereas PKI tokens are big, self-signed, and can be validated
offline.

You can choose which format you'd like by setting keystone.conf [TOKEN]
token_format (PKI is the default).

On Saturday, April 13, 2013, Daniel Ellison wrote:

> On 2013-04-13, at 5:24 PM, Dolph Mathews 
> >
> wrote:
> > Hmm, well it looks like you already have debug enabled, which is
> indicating that the username + password combination is bad (if debug was
> disabled, you'd get a much more opaque error message). The tenant name you
> specified would not have been checked yet. If 'admin' appears in your
> keystone user-list, then the password is definitely wrong.
>
> Success! I deleted the admin user and then recreated it using a new,
> unique password. I removed OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT from my
> environment. Then I did 'keystone token-get' and got a proper response!
>
> Thanks so much for the suggestion, Dolph. One further question: Is the
> "id" part of the received token supposed to be ridiculously long? I got an
> id that is 836 characters long! The examples in "Verifying the Identity
> Service Installation" are the same length as the user_id: 32 characters. I
> just want to be sure everything is working as it should.
>
> Thanks,
> Daniel
>
>
>

-- 

-Dolph
___
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 Woes

[Dolph Mathews]

Hmm, well it looks like you already have debug enabled, which is indicating
that the username + password combination is bad (if debug was disabled,
you'd get a much more opaque error message). The tenant name you specified
would not have been checked yet. If 'admin' appears in your keystone
user-list, then the password is definitely wrong.


-Dolph


On Sat, Apr 13, 2013 at 3:56 PM, Daniel Ellison  wrote:

> On 2013-04-13, at 1:24 PM, Dolph Mathews  wrote:
> > It looks like you're doing everything correctly, except OS_PASSWORD is
> *NOT* the same thing as the static admin_token in keystone.conf.
>
> You're right, actually. I DID use the admin_token for OS_PASSWORD. I'll
> definitely be fixing that. But as long as the password is set and
> referenced properly it shouldn't matter what it is, I would hope.
>
> > Passwords are user-specific attributes created using the --pass argument
> on user-create for example. You may have set it to be the same as
> keystone.conf's admin_token, but I necessarily wouldn't recommend that. If
> you don't know what your password was, you probably need to delete your
> admin user and recreate it with a known password, and then grant it your
> admin role again.
>
> The keystone_data.sh script did this correctly, using the ADMIN_PASSWORD I
> set at the top of the script. That password happened to be the admin_token,
> but again, as long as it's set properly it shouldn't make a difference. As
> I mentioned, I think I'll fix that anyway, just to take it out of the
> equation.
>
> Thanks for the response!
> Daniel
___
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 Woes

[Dolph Mathews]

It looks like you're doing everything correctly, except OS_PASSWORD is
*NOT* the same thing as the static admin_token in keystone.conf.

Passwords are user-specific attributes created using the --pass argument on
user-create for example. You may have set it to be the same as
keystone.conf's admin_token, but I necessarily wouldn't recommend that. If
you don't know what your password was, you probably need to delete your
admin user and recreate it with a known password, and then grant it your
admin role again.


-Dolph


On Sat, Apr 13, 2013 at 12:13 PM, Daniel Ellison  wrote:

> Hi all,
>
> I joined this list just now to solve a particular problem, but once I'm
> past this I hope to be giving back to the community.
>
> I have spent the past week trying to get Keystone installed and configured
> properly. I want to show a running OpenStack to my manager for a proof of
> concept I want to build, so I'm installing everything on a server which has
> a public IP. I don't have more servers, so I'm attempting to install
> everything on one machine. (Yes, I have a good firewall in place on which I
> have yet to open Keystone's ports. But I have the same issue with or
> without a firewall.)
>
> The server's OS is Ubuntu 12.04. I'm attempting to install the 'grizzly'
> release. MySQL is there, and I'm using this as a connection string:
>
> connection = mysql://keystone:openstack@204.187.138.2/keystone
>
> I have my own admin token set. I used the endpoints.sh and
> keystone_data.sh scripts to set up the database. Yes, I restarted the
> keystone service. :) I even went through the same process manually to make
> sure everything was in place. I logged into MySQL and poked around but
> everything seemed ok.
>
> Using the 'keystone' Python client on the server itself I can successfully
> execute user-list, endpoint-list, user-get, etc. But when I try to get a
> token with 'keystone token-get' I get:
>
> Configuration error: Client configured to run without a service
> catalog. Run the client using --os-auth-url or OS_AUTH_URL, instead of
> --os-endpoint or OS_SERVICE_ENDPOINT, for example.
>
> My environment contains:
>
> export OS_TENANT_NAME=admin
> export OS_USERNAME=admin
> export OS_PASSWORD=
> export OS_AUTH_URL="http://204.187.138.2:5000/v2.0/";
> export OS_SERVICE_ENDPOINT="http://204.187.138.2:35357/v2.0";
> export OS_SERVICE_TOKEN=
>
> When I unset OS_SERVICE_ENDPOINT and OS_SERVICE_TOKEN (because I read
> somewhere these two are used as a pair) and execute
>
> keystone --os-username=admin --os-password= --os-auth-url=
> http://204.187.138.2:5000/v2.0 token-get
>
> I get this in response:
>
> Unable to communicate with identity service: {"error": {"message":
> "Invalid user / password", "code": 401, "title": "Not Authorized"}}. (HTTP
> 401)
>
> I've tried a seemingly infinite combination of usernames, passwords,
> tenants, etc. and nothing has worked. If someone could point me in the
> right direction I'd be very grateful. I'll answer any questions needed to
> get past this point.
>
> Thanks in advance,
> Daniel
> ___
> 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

Re: [Openstack] [Folfsom][Cinder] cinder list ERROR: Malformed request url (HTTP 400)

[Dolph Mathews]

There's a backslash in your endpoints and a stray closing paren at the end:

  http://192.168.122.215:8776/v1/$(tenant_id)s)

Keystone supports two formats here so you don't have to try and escape
anything. Recreate your endpoints with whichever one of the following you
prefer:

  
http://192.168.122.215:8776/v1/$(tenant_id)s
  
http://192.168.122.215:8776/v1/%(tenant_id)s


-Dolph


On Fri, Apr 5, 2013 at 7:58 AM, Arindam Choudhury  wrote:

> [(keystone_user)]$ cinder --debug list
> connect: (158.109.65.21, 5000) 
> send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: 
> 158.109.65.21:5000\r\nContent-Length:
> 97\r\ncontent-type: application/json\r\naccept-encoding: gzip,
> deflate\r\naccept: application/json\r\nuser-agent:
> python-cinderclient\r\n\r\n{"auth": {"tenantName": "user",
> "passwordCredentials": {"username": "user", "password": "user"}}}'
> reply: 'HTTP/1.1 200 OK\r\n'
> header: Vary: X-Auth-Token
> header: Content-Type: application/json
> header: Date: Fri, 05 Apr 2013 11:26:46 GMT
> header: Transfer-Encoding: chunked
> connect: (158.109.65.21, 8776) 
> send: u'GET /v1/\\e50f4b99747849bfade38bc8a7734731)/volumes/detail
> HTTP/1.1\r\nHost: 158.109.65.21:8776\r\nx-auth-project-id:
> user\r\nx-auth-token: a0712823eddc42b6b73dab6ae0a88097\r\naccept-encoding:
> gzip, deflate\r\naccept: application/json\r\nuser-agent:
> python-cinderclient\r\n\r\n'
> reply: 'HTTP/1.1 400 Bad Request\r\n'
> header: Content-Length: 65
> header: Content-Type: application/json; charset=UTF-8
> header: X-Compute-Request-Id: req-3f84bc89-e5a0-47f7-b5b1-b1a9e4293eba
> header: Date: Fri, 05 Apr 2013 11:26:46 GMT
> DEBUG (shell:480) Malformed request url (HTTP 400) (Request-ID:
> req-3f84bc89-e5a0-47f7-b5b1-b1a9e4293eba)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/cinderclient/shell.py", line 477,
> in main
> OpenStackCinderShell().main(sys.argv[1:])
>   File "/usr/lib/python2.7/site-packages/cinderclient/shell.py", line 428,
> in main
> args.func(self.cs, args)
>   File "/usr/lib/python2.7/site-packages/cinderclient/v1/shell.py", line
> 143, in do_list
> volumes = cs.volumes.list(search_opts=search_opts)
>   File "/usr/lib/python2.7/site-packages/cinderclient/v1/volumes.py", line
> 184, in list
> "volumes")
>   File "/usr/lib/python2.7/site-packages/cinderclient/base.py", line 63,
> in _list
> resp, body = self.api.client.get(url)
>   File "/usr/lib/python2.7/site-packages/cinderclient/client.py", line
> 162, in get
> return self._cs_request(url, 'GET', **kwargs)
>   File "/usr/lib/python2.7/site-packages/cinderclient/client.py", line
> 131, in _cs_request
> **kwargs)
>   File "/usr/lib/python2.7/site-packages/cinderclient/client.py", line
> 114, in request
> raise exceptions.from_response(resp, body)
> BadRequest: Malformed request url (HTTP 400) (Request-ID:
> req-3f84bc89-e5a0-47f7-b5b1-b1a9e4293eba)
> ERROR: Malformed request url (HTTP 400) (Request-ID:
> req-3f84bc89-e5a0-47f7-b5b1-b1a9e4293eba)
> [(keystone_user)]$
>
>
> --
> From: arin...@live.com
> To: openstack@lists.launchpad.net
> Date: Fri, 5 Apr 2013 12:29:20 +0200
> Subject: [Openstack] [Folfsom][Cinder] cinder list ERROR: Malformed
> request url (HTTP 400)
>
>
> Hi,
>
> I am trying to install OpenStack Folsom on Fedora 18. So far I have
> installed:
>
> $ openstack-status
> == Glance services ==
> openstack-glance-api: active
> openstack-glance-registry:active
> == Keystone service ==
> openstack-keystone:   active
> == Cinder services ==
> openstack-cinder-api: active
> openstack-cinder-scheduler:   active
> openstack-cinder-volume:  active
> == Support services ==
> libvirtd: active
> tgtd: active
> qpidd:active
> memcached:inactive (disabled on boot)
>
> When I tried to run cinder list, I get this error:
> [(keystone_user)]$ cinder list
> ERROR: Malformed request url (HTTP 400) (Request-ID:
> req-3692a984-8750-47a5-a673-1db9d5fd217a)
>
>
> The instructons I have followed are as follows:
>
> # yum install openstack-cinder -y
> # openstack-db --init --service cinder
> # openstack-config --set /etc/cinder/cinder.conf DEFAULT auth_strategy
> keystone
> # openstack-config --set /etc/cinder/cinder.conf keystone_authtoken
> admin_tenant_name admin
> # openstack-config --set /etc/cinder/cinder.conf keystone_authtoken
> admin_user admin
> # openstack-config --set /etc/cinder/cinder.conf keystone_authtoken
> admin_password admin
> # grep -q /etc/cinder/volumes /etc/tgt/targets.conf || sed -i '1iinclude
> /etc/cinder/volumes/*' /etc/tgt/targets.conf
> # service tgtd start
> # chkconfig tgtd on
> # truncate --size 20G ~/cinder-volumes
> # losetup -fv ~/cinder-volumes
> # vgcreate cinder-volumes /dev/loop0
>   No physical volume label read from 

Re: [Openstack] error configuring keystone

[Dolph Mathews]

An OS_SERVICE_ENDPOINT and/or OS_SERVICE_TOKEN are defined in your
environment, and are taking precedence over the credentials you're
providing on the command line -- I'm not a fan of this behavior myself :(

unset the endpoint & token from env, and token-get should behave as
expected.

-Dolph


On Tue, Apr 2, 2013 at 10:24 AM, Arindam Choudhury  wrote:

> Hi,
>
> I am new to OpenStack. I am trying to install OpenStack Folsom on Fedora
> 18.
>
> I am following the online documentation. I am getting this error while
> configuring keystone:
>
> [root@XX ~]# keystone --os-username=admin --os-password=admin
> --os-auth-url=http://XX:35357/v2.0 token-get
> WARNING: Bypassing authentication using a token & endpoint (authentication
> credentials are being ignored).
> Configuration error: Client configured to run without a service catalog.
> Run the client using --os-auth-url or OS_AUTH_URL, instead of --os-endpoint
> or OS_SERVICE_ENDPOINT, for example.
>
>
> any help will be highly appreciated.
>
> [root@XX ~]# keystone tenant-list
> +--+-+-+
> |id| name| enabled |
> +--+-+-+
> | d9e967e6a5eb424e81831a728a5347ca | admintenant |   True  |
> | f0c5c0dc38d8411ab07059c4051d98e4 |   service   |   True  |
> +--+-+-+
> [root@XX ~]# keystone user-list
> +--++-+---+
> |id|  name  | enabled | email |
> +--++-+---+
> | 28284c04ac6f4782b09fb7c662ce5a80 | glance |   True  |   |
> | 99c6a8b376ca4b6fa9c3e3dad37271d7 |  nova  |   True  |   |
> | a8d5cc5b899e4c7f90db6f50d6d46491 | admin  |   True  |   |
> | db3ff8a6cbaa465d8dbee7c7868ae897 | swift  |   True  |   |
> +--++-+---+
> [root@XX ~]# keystone role-list
> +--+---+
> |id|  name |
> +--+---+
> | 2fd4d8c89f9645eeb43809b219622d97 | admin |
> +--+---+
> [root@XX ~]# keystone user-role-list
> --user-id=a8d5cc5b899e4c7f90db6f50d6d46491
> --tenant-id=d9e967e6a5eb424e81831a728a5347ca
>
> +--+---+--+--+
> |id|  name |
> user_id  |tenant_id |
>
> +--+---+--+--+
> | 2fd4d8c89f9645eeb43809b219622d97 | admin |
> a8d5cc5b899e4c7f90db6f50d6d46491 | d9e967e6a5eb424e81831a728a5347ca |
>
> +--+---+--+--+
> [root@XX ~]# keystone service-list
>
> +--+--+--++
> |id|   name   | type |
> description   |
>
> +--+--+--++
> | 043f8c23d9234618830623375aacfedb |  glance  |image | Image
> Service  |
> | 49f4a54da885427d8b0c729030d4dcc9 |   nova   |   compute|Compute
> Service |
> | 9cf4dbfce836418c96f6af9e2bcf52ee |  swift   | object-store | Object
> Storage Service |
> | c8c454fe1bb44e87bdfd6a203575ee47 | keystone |   identity   |Identity
> Service|
> | f66987f86728440f85e69f9a019cc362 |  volume  |volume| Volume
> Service |
>
> +--+--+--++
> [root@XX ~]# keystone endpoint-list
>
> +--+---+-+-++--+
> |id|   region  |
> publicurl|
> internalurl   |  adminurl
> |service_id|
>
> +--+---+-+-++--+
> | 2df0b5bc99e44b1fae152b561b97455e | RegionOne |http://XX:9292
> |http://XX:9292| http://XX:9292
> | 043f8c23d9234618830623375aacfedb |
> | 35e6cc4cfc2b4b2d91c268e6a8d6a650 | RegionOne |
> http://XX:/v1/AUTH_%(tenant_id)s |
> http://XX:/v1/AUTH_%(tenant_id)s |http://XX:/v1|
> 9cf4dbfce836418c96f6af9e2bcf52ee |
> | 3bae160b577a46bd8dc7d6b732e22b36 | RegionOne |
> http://XX:8774/v2/%(tenant_id)s   |http://XX

Re: [Openstack] Keystone Too Many Connections Problem

[Dolph Mathews]

Thanks! I was able to reproduce and I've proposed a fix to both master and
grizzly.

master- https://review.openstack.org/#/c/25831/
grizzly- https://review.openstack.org/#/c/25833/

If you can verify this patch on your system, that would be really helpful.


-Dolph


On Mon, Apr 1, 2013 at 1:57 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Dolph,
>
> ** **
>
> [token]
>
> driver = keystone.token.backends.sql.Token
>
> ** **
>
> # Amount of time a token should remain valid (in seconds)
>
> expiration = 86400
>
> ** **
>
> I get the same results for either UUID or PKI tokens.****
>
> ** **
>
> Mark
>
> ** **
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* Monday, April 01, 2013 11:56 AM
>
> *To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis)
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Keystone Too Many Connections Problem
>
>  ** **
>
> Mark,
>
> ** **
>
> Which token driver are you using?
>
> ** **
>
> -Dolph
>
> ** **
>
> On Mon, Apr 1, 2013 at 10:49 AM, Dolph Mathews 
> wrote:
>
> I also opened bug 1162857, which produces a slightly different symptom
> with a different configuration (sqlite), but may share the same underlying
> cause.
>
>
> 
>
> ** **
>
> -Dolph
>
> ** **
>
> On Mon, Apr 1, 2013 at 10:26 AM, Dolph Mathews 
> wrote:
>
> I'm attempting to reproduce this now (haven't been successful with PKI +
> sqlite on disk), but in the meantime I opened a bug on this issue for
> tracking:
>
> ** **
>
>   https://bugs.launchpad.net/keystone/+bug/1162845
>
>
> 
>
> ** **
>
> -Dolph
>
> ** **
>
> On Fri, Mar 29, 2013 at 1:35 PM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)  wrote:
>
>   Hi,
>
>  
>
> I have a loop that gets PKI tokens from Keystone (RC2). After about 116
> loops I get the following error and have to reset Keystone to continue. Has
> anyone else run into this?
>
>  
>
> Thanks,
>
>  
>
> Mark
>
>  
>
> (keystone.auth.controllers): 2013-03-29 11:14:01,274 ERROR
> (OperationalError) (1040, 'Too many connections') None None
>
> Traceback (most recent call last):
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
> line 286, in authenticate_for_token
>
> self.authenticate(context, auth_info, auth_context)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
> line 352, in authenticate
>
> auth_context)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 108, in authenticate
>
> user_info = UserAuthInfo(context, auth_payload)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 36, in __init__
>
> self._validate_and_normalize_auth_data(auth_payload)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 87, in _validate_and_normalize_auth_data
>
> domain_ref = self._lookup_domain(user_info['domain'])
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 60, in _lookup_domain
>
> context=self.context, domain_name=domain_name)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/manager.py",
> line 47, in _wrapper
>
> return f(*args, **kw)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/sql/core.py",
> line 272, in wrapper
>
> return method(*args, **kwargs)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/identity/backends/sql.py",
> line 589, in get_domain_by_name
>
> ref = session.query(Domain).filter_by(name=domain_name).one()
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
> line 2184, in one
>
> ret = list(self)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalche

Re: [Openstack] Keystone Too Many Connections Problem

[Dolph Mathews]

Mark,

Which token driver are you using?

-Dolph


On Mon, Apr 1, 2013 at 10:49 AM, Dolph Mathews wrote:

> I also opened bug 1162857, which produces a slightly different symptom
> with a different configuration (sqlite), but may share the same underlying
> cause.
>
>
> -Dolph
>
>
> On Mon, Apr 1, 2013 at 10:26 AM, Dolph Mathews wrote:
>
>> I'm attempting to reproduce this now (haven't been successful with PKI +
>> sqlite on disk), but in the meantime I opened a bug on this issue for
>> tracking:
>>
>>   https://bugs.launchpad.net/keystone/+bug/1162845
>>
>>
>> -Dolph
>>
>>
>> On Fri, Mar 29, 2013 at 1:35 PM, Miller, Mark M (EB SW Cloud - R&D -
>> Corvallis)  wrote:
>>
>>>  Hi,
>>>
>>> ** **
>>>
>>> I have a loop that gets PKI tokens from Keystone (RC2). After about 116
>>> loops I get the following error and have to reset Keystone to continue. Has
>>> anyone else run into this?
>>>
>>> ** **
>>>
>>> Thanks,
>>>
>>> ** **
>>>
>>> Mark
>>>
>>> ** **
>>>
>>> (keystone.auth.controllers): 2013-03-29 11:14:01,274 ERROR
>>> (OperationalError) (1040, 'Too many connections') None None
>>>
>>> Traceback (most recent call last):
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
>>> line 286, in authenticate_for_token
>>>
>>> self.authenticate(context, auth_info, auth_context)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
>>> line 352, in authenticate
>>>
>>> auth_context)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>>> line 108, in authenticate
>>>
>>> user_info = UserAuthInfo(context, auth_payload)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>>> line 36, in __init__
>>>
>>> self._validate_and_normalize_auth_data(auth_payload)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>>> line 87, in _validate_and_normalize_auth_data
>>>
>>> domain_ref = self._lookup_domain(user_info['domain'])
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>>> line 60, in _lookup_domain
>>>
>>> context=self.context, domain_name=domain_name)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/manager.py",
>>> line 47, in _wrapper
>>>
>>> return f(*args, **kw)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/sql/core.py",
>>> line 272, in wrapper
>>>
>>> return method(*args, **kwargs)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/identity/backends/sql.py",
>>> line 589, in get_domain_by_name
>>>
>>> ref = session.query(Domain).filter_by(name=domain_name).one()
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>>> line 2184, in one
>>>
>>> ret = list(self)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>>> line 2227, in __iter__
>>>
>>> return self._execute_and_instances(context)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>>> line 2240, in _execute_and_instances
>>>
>>> close_with_result=True)
>>>
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/o

Re: [Openstack] Keystone Too Many Connections Problem

[Dolph Mathews]

I also opened bug 1162857, which produces a slightly different symptom with
a different configuration (sqlite), but may share the same underlying cause.


-Dolph


On Mon, Apr 1, 2013 at 10:26 AM, Dolph Mathews wrote:

> I'm attempting to reproduce this now (haven't been successful with PKI +
> sqlite on disk), but in the meantime I opened a bug on this issue for
> tracking:
>
>   https://bugs.launchpad.net/keystone/+bug/1162845
>
>
> -Dolph
>
>
> On Fri, Mar 29, 2013 at 1:35 PM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)  wrote:
>
>>  Hi,
>>
>> ** **
>>
>> I have a loop that gets PKI tokens from Keystone (RC2). After about 116
>> loops I get the following error and have to reset Keystone to continue. Has
>> anyone else run into this?
>>
>> ** **
>>
>> Thanks,
>>
>> ** **
>>
>> Mark
>>
>> ** **
>>
>> (keystone.auth.controllers): 2013-03-29 11:14:01,274 ERROR
>> (OperationalError) (1040, 'Too many connections') None None
>>
>> Traceback (most recent call last):
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
>> line 286, in authenticate_for_token
>>
>> self.authenticate(context, auth_info, auth_context)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
>> line 352, in authenticate
>>
>> auth_context)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>> line 108, in authenticate
>>
>> user_info = UserAuthInfo(context, auth_payload)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>> line 36, in __init__
>>
>> self._validate_and_normalize_auth_data(auth_payload)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>> line 87, in _validate_and_normalize_auth_data
>>
>> domain_ref = self._lookup_domain(user_info['domain'])
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
>> line 60, in _lookup_domain
>>
>> context=self.context, domain_name=domain_name)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/manager.py",
>> line 47, in _wrapper
>>
>> return f(*args, **kw)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/sql/core.py",
>> line 272, in wrapper
>>
>> return method(*args, **kwargs)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/identity/backends/sql.py",
>> line 589, in get_domain_by_name
>>
>> ref = session.query(Domain).filter_by(name=domain_name).one()
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>> line 2184, in one
>>
>> ret = list(self)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>> line 2227, in __iter__
>>
>> return self._execute_and_instances(context)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>> line 2240, in _execute_and_instances
>>
>> close_with_result=True)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
>> line 2231, in _connection_from_session
>>
>> **kw)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/session.py",
>> line 777, in connection
>>
>> close_with_result=close_with_result)
>>
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/session.py",
>> line 783, in _connection_for_bind
>>
>> return engine.contextual_connect(

Re: [Openstack] Keystone Too Many Connections Problem

[Dolph Mathews]

I'm attempting to reproduce this now (haven't been successful with PKI +
sqlite on disk), but in the meantime I opened a bug on this issue for
tracking:

  https://bugs.launchpad.net/keystone/+bug/1162845


-Dolph


On Fri, Mar 29, 2013 at 1:35 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hi,
>
> ** **
>
> I have a loop that gets PKI tokens from Keystone (RC2). After about 116
> loops I get the following error and have to reset Keystone to continue. Has
> anyone else run into this?
>
> ** **
>
> Thanks,
>
> ** **
>
> Mark
>
> ** **
>
> (keystone.auth.controllers): 2013-03-29 11:14:01,274 ERROR
> (OperationalError) (1040, 'Too many connections') None None
>
> Traceback (most recent call last):
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
> line 286, in authenticate_for_token
>
> self.authenticate(context, auth_info, auth_context)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/controllers.py",
> line 352, in authenticate
>
> auth_context)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 108, in authenticate
>
> user_info = UserAuthInfo(context, auth_payload)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 36, in __init__
>
> self._validate_and_normalize_auth_data(auth_payload)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 87, in _validate_and_normalize_auth_data
>
> domain_ref = self._lookup_domain(user_info['domain'])
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/auth/plugins/password.py",
> line 60, in _lookup_domain
>
> context=self.context, domain_name=domain_name)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/manager.py",
> line 47, in _wrapper
>
> return f(*args, **kw)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/common/sql/core.py",
> line 272, in wrapper
>
> return method(*args, **kwargs)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.rc2-py2.7.egg/keystone/identity/backends/sql.py",
> line 589, in get_domain_by_name
>
> ref = session.query(Domain).filter_by(name=domain_name).one()
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
> line 2184, in one
>
> ret = list(self)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
> line 2227, in __iter__
>
> return self._execute_and_instances(context)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
> line 2240, in _execute_and_instances
>
> close_with_result=True)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/query.py",
> line 2231, in _connection_from_session
>
> **kw)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/session.py",
> line 777, in connection
>
> close_with_result=close_with_result)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/orm/session.py",
> line 783, in _connection_for_bind
>
> return engine.contextual_connect(**kwargs)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/engine/base.py",
> line 2489, in contextual_connect
>
> self.pool.connect(),
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/pool.py",
> line 236, in connect
>
> return _ConnectionFairy(self).checkout()
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/pool.py",
> line 401, in __init__
>
> rec = self._connection_record = pool._do_get()
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/pool.py",
> line 746, in _do_get
>
> con = self._create_connection()
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/pool.py",
> line 189, in _create_connection
>
> return _ConnectionRecord(self)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/pool.py",
> line 282, in __init__
>
> self.connection = self.__connect()
>
>   File
> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-l

Re: [Openstack] Keystone Grizzly RC2 available

[Dolph Mathews]

It wasn't proposed for backporting nor did jenkins link the bug to the
review:

Review: https://review.openstack.org/#/c/24965/

Bug: https://bugs.launchpad.net/keystone/+bug/1159987

Commit:
https://github.com/openstack/keystone/commit/2f0c46179ea2eb7872167941412bdbd5abca08f0

I tagged the bug as grizzly-backport-potential as it's certainly low impact
and desirable.


-Dolph


On Thu, Mar 28, 2013 at 2:40 PM, Brad Topol  wrote:

> Andy,
>
> Was there a blueprint for this function?  Can I get the review ID?   I am
> very interested in the notion of  custom token creation.
>
> Thanks,
>
> Brad
>
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet:  bto...@us.ibm.com
> Assistant: Cindy Willman (919) 268-5296
>
>
>
> From:Andy Smith 
> To:Thierry Carrez 
> Cc:"openstack@lists.launchpad.net" 
> Date:03/28/2013 03:27 PM
> Subject:Re: [Openstack] Keystone Grizzly RC2 available
> Sent by:openstack-bounces+btopol=us.ibm@lists.launchpad.net
> --
>
>
>
> The change I made to build tokens from existing data (rather than
> re-querying it all from the db) didn't go in?
>
> Without it extensions are not able to build custom tokens (meaning just
> about any extension that wants to do something with auth is not possible).
>
>
> On Thu, Mar 28, 2013 at 2:34 AM, Thierry Carrez 
> <*thie...@openstack.org*>
> wrote:
> Hello everyone,
>
> Due to the renaming of the trust extension and a response backward
> compatibility issue, we created a new Grizzly release candidate for
> OpenStack identity ("Keystone").
>
> You can find the RC2 tarball and the list of fixed bugs at:*
> **https://launchpad.net/keystone/grizzly/grizzly-rc2*
>
> This is hopefully the last Grizzly release candidate for Keystone.
> Unless new release-critical regressions are found that warrant another
> release candidate respin, this RC2 will be formally included in the
> common OpenStack 2013.1 final release next week. You are therefore
> strongly encouraged to test and validate this tarball.
>
> Alternatively, you can grab the code at:*
> **https://github.com/openstack/keystone/tree/milestone-proposed*
>
> If you find a regression that could be considered release-critical,
> please file it at 
> *https://bugs.launchpad.net/keystone/+filebug*and
>  tag
> it *grizzly-rc-potential* to bring it to the release crew's attention.
>
> Happy regression hunting,
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> ___
> 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
>
>
___
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] Project quotas on multi-region

[Dolph Mathews]

Centralized quotas in keystone: http://summit.openstack.org/cfp/details/83


-Dolph


On Wed, Mar 27, 2013 at 6:46 AM, Tom Fifield wrote:

> On 24/03/13 23:36, Tim Bell wrote:
> >
> >
> > The Boson project was looking at this sort of problem
> > (https://wiki.openstack.org/wiki/Boson).
> >
> >
> >
> > There is a session at the summit to review this and other activities
> > since it appears quotas are appearing in many projects and there is a
> > clear need for multi-cell and quota delegation (i.e. domain quota
> > manager gives sub-sections to project quota managers). This sort of
> > function is quite complex to implement and consistency of implementation
> > would be strongly desirable.
>
> Indeed. Cells right now supports the centralised quotas that Glaucimar
> needs, but doesn't deal with situations where certain projects have
> quotas on certain cells.
>
> >
> >
> >
> > Tim
> >
> >
> >
> > *From:*openstack-bounces+tim.bell=cern...@lists.launchpad.net
> > [mailto:openstack-bounces+tim.bell=cern...@lists.launchpad.net] *On
> > Behalf Of *Nathanael Burton
> > *Sent:* 24 March 2013 02:31
> > *To:* Aguiar, Glaucimar (Brazil R&D-ECL)
> > *Cc:* OpenStack Development Mailing List; openstack@lists.launchpad.net
> > *Subject:* Re: [Openstack] Project quotas on multi-region
> >
> >
> >
> > On Mar 23, 2013 7:59 PM, "Aguiar, Glaucimar (Brazil R&D-ECL)"
> > mailto:glaucimar.agu...@hp.com>> wrote:
> >>
> >> Hi,
> >>
> >> In a deployment scenario where one keystone has several regions
> > registered, how the project quota are managed by, as an example, two
> > nova services in two different regions?
> >> I am wondering if is it possible to set quota on the project for all
> > regions or this must to be done on a region by region basis which really
> > means a quota for a project in a region.
> >>
> >> Thanks in advance,
> >> Glaucimar Aguiar
> >>
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@lists.launchpad.net
> > 
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > Glaucimar,
> >
> > Currently quotas are maintained within each nova system so there is not
> > a global view/management/enforcement of quotas. I would love to see a
> > discussion of centralizing things from nova like key pairs, AZs, and
> > quotas in keystone.
> >
> > Thanks,
> >
> > Nate
> >
> >
> >
> > ___
> > 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

Re: [Openstack] Error while trying to login to Devstack dashboard

[Dolph Mathews]

Make sure that the certs created by pki_setup are readable by the user
running keystone-all


-Dolph


On Tue, Mar 19, 2013 at 12:19 PM, Abhishek Chanda
wrote:

> I actually did that and when I ran keystone-all again, I got the same
> error. The console log in my first mail shows this. Sorry for being vague
> about this.
>
> *abhishek@abhishek-VirtualBox:~$ sudo keystone-manage pki_setup*
> abhishek@abhishek-VirtualBox:~$ keystone-all
> /usr/local/lib/python2.7/dist-packages/sqlalchemy/pool.py:703:
> SADeprecationWarning: The 'listeners' argument to Pool (and
> create_engine()) is deprecated.  Use event.listen().
>   Pool.__init__(self, creator, **kw)
> /usr/local/lib/python2.7/dist-packages/sqlalchemy/pool.py:160:
> SADeprecationWarning: Pool.add_listener is deprecated.  Use event.listen()
>   self.add_listener(l)
> 2013-03-18 13:30:55ERROR [keystone.common.cms] Signing error: Unable
> to load certificate - ensure you've configured PKI with 'keystone-manage
> pki_setup'
> 2013-03-18 13:30:55  WARNING [keystone.common.wsgi] Unable to sign token.
>
> Thanks
>
>
> On Tue, Mar 19, 2013 at 4:53 AM, Chmouel Boudjnah wrote:
>
>> On Mon, Mar 18, 2013 at 7:03 PM, Abhishek Chanda
>>  wrote:
>> > 2013-03-18 13:30:55ERROR [keystone.common.cms] Signing error:
>> Unable to
>> > load certificate - ensure you've configured PKI with 'keystone-manage
>> > pki_setup'
>>
>>
>> perhaps by doing this?
>>
>> Chmouel.
>>
>> ___
>> 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

Re: [Openstack] Issues with latests trunk

[Dolph Mathews]

What is the protocol of your sql connection string in keystone.conf?
mysql+mysqldb:// ? If so, try changing it to just mysql:// which I think
will match what python-mysql installs.

  http://docs.sqlalchemy.org/en/rel_0_7/core/engines.html#database-urls


-Dolph


On Tue, Mar 19, 2013 at 6:17 PM, Tyler North  wrote:

> Avinash, thank you for your response. The python-mysql adapter was
> installed on the machine, I just tried updating it but still got the same
> error
>
>
>
> On Tue, Mar 12, 2013 at 9:29 PM, Prasad, Avinash <
> avinash.pra...@nttdata.com> wrote:
>
>>  Hi,
>> Is the MySQL adapter for python isntalled in your machine. Because the
>> error corresponds to th unavailability of the MySQLdb adapter.
>>
>> Kindly have a look into that.
>>
>> Regards,
>> Avinash
>>  --
>> *From:* 
>> openstack-bounces+avinash.prasad=nttdata@lists.launchpad.net[openstack-bounces+avinash.prasad=
>> nttdata@lists.launchpad.net] on behalf of Tyler North [
>> tyl...@pistoncloud.com]
>> *Sent:* Tuesday, March 12, 2013 6:05 PM
>> *To:* openstack@lists.launchpad.net
>> *Subject:* [Openstack] Issues with latests trunk
>>
>>   Hey everyone,
>>
>>  I'm trying to run the latest version of devstack-trunk( latest commit
>> on git log is: 87387596631602b5f676eae65823b4f0c5c71e66a).
>>
>>  Im running it currently on Ubuntu 12.04 and whenever I run ./stack.sh I
>> get the following error:
>>
>>
>> Unable to communicate with identity service: {"error": {"message": "An
>> unexpected error prevented the server from fulfilling your request. No
>> module named MySQLdb", "code": 500, "title": "Internal Server Error"}}.
>> (HTTP 500)
>> + KEYSTONE_SERVICE=
>> + keystone endpoint-create --region RegionOne --service_id --publicurl
>> http://10.1.10.231:5000/v2.0 --adminurl 
>> http://10.1.10.231:35357/v2.0--internalurl
>> http://10.1.10.231:5000/v2.0
>> usage: keystone endpoint-create [--region ] --service-id
>>  [--publicurl ]
>> [--adminurl ]
>> [--internalurl ]
>> keystone endpoint-create: error: argument --service-id/--service_id:
>> expected one argument
>>
>>
>>  Any help as to where to look for /solve the problem would be appreciated
>>
>> Thanks
>>  Tyler
>>
>> __
>> Disclaimer:This email and any attachments are sent in strictest
>> confidence for the sole use of the addressee and may contain legally
>> privileged, confidential, and proprietary data. If you are not the intended
>> recipient, please advise the sender by replying promptly to this email and
>> then delete and destroy this email and any attachments without any further
>> use, copying or forwarding
>>
>
>
> ___
> 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

Re: [Openstack] Endpoint question

[Dolph Mathews]

**Ideally** you would provide unversioned endpoints for all services, e.g.:

  http://keystone:35357/ instead of http://keystone:35357/v2.0/

... and the client would work out what versions are supported and select a
preferred version automatically.

However, we're not quite there yet. I can't speak for nova and glance at
the moment, but there will probably continue to have "recommended"
endpoints for use in the catalog.

For Havana, I would recommend /v2.0/ for keystone at this point (at least
for the catalog), unless you know the client you're configuring supports
properly supports an unversioned endpoint (auth_token) or a v3 endpoint
(python-keystoneclient's python API, openstackclient, and auth_token).


-Dolph


On Thu, Mar 14, 2013 at 5:41 PM, Logan McNaughton wrote:

> I have a question on service endpoints.
> I've read that Horizon depends quite heavily on them, and a
> misconfiguration there can really mess things up. My question is, does the
> endpoint need to be compatible with Horizon?
>
> For instance, as of Grizzly, Keystone will support /v2.0 and /v3
> Nova will support /v1.1 and /v2
> Glance will support /v1 and /v2
> Quantum will support a /v2
>
> Can I safely use the latest endpoints (For instance, Keystone /v3), or
> does Horizon only support certain endpoint versions? Can I have multiple
> endpoints and create a /v2.0 and /v3?
>
> ___
> 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

Re: [Openstack] Resolved: Grizzly-3 Keystone SSL Connection Refused

[Dolph Mathews]

Glad you got it resolved, but can you file a bug on pki_setup not
generating SSL certs? I don't believe I've seen that issue.
https://bugs.launchpad.net/keystone

Thanks!


-Dolph


On Thu, Mar 14, 2013 at 4:58 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Looks like there’s a bug in pki_setup. It didn’t generate the SSL certs,
> only the signing certs. Workaround is to make ssl using the signing certs
> for now.
>
> ** **
>
> [ssl]
>
> enable = True
>
> certfile = /etc/keystone/ssl/certs/signing_cert.pem
>
> keyfile = /etc/keystone/ssl/private/signing_key.pem
>
> ca_certs = /etc/keystone/ssl/certs/ca.pem
>
> cert_required = False
>
> ** **
>
> Also, if your keystone process is not running as root, make sure the file
> permissions for the pem files are set properly.
>
> ** **
>
> Guang
>
> ** **
>
> ** **
>
> *From:* openstack-bounces+mark.m.miller=hp@lists.launchpad.net[mailto:
> openstack-bounces+mark.m.miller=hp@lists.launchpad.net] *On Behalf Of
> *Miller, Mark M (EB SW Cloud - R&D - Corvallis)
> *Sent:* Thursday, March 14, 2013 2:31 PM
> *To:* openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> *Subject:* [Openstack] Grizzly-3 Keystone SSL Connection Refused
>
> ** **
>
> Hello,
>
> ** **
>
> I was able to setup a Grizzly-2 Keystone server with PKI and SSL enabled
> on an Ubuntu 12.04 server. I updated to Grizzly-3 and am able to enable PKI
> but not SSL. I get “Connection refused”. Has anyone else run into this
> problem? Does anyone else have SSL working with Grizzly-3 Keystone?
>
> ** **
>
> Regards,
>
> ** **
>
> Mark
>
> ___
> 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

Re: [Openstack] Keystone - Domain admin role policies?

[Dolph Mathews]

That's exactly our goal, but I'm not sure that corresponding well-tested
policy.json changes will land in time for Grizzly (also not sure if there
would be any other supporting changes required).

Adding Brant as he specifically was investigating the same possibility in
Grizzly.


-Dolph


On Tue, Mar 12, 2013 at 8:57 AM, Aguiar, Glaucimar (Brazil R&D-ECL) <
glaucimar.agu...@hp.com> wrote:

> Please note that I know one can edit policy.json to define domain-admin
> role permissions but with the implementation of domains, it seems that
> domain-admin role permissions should be defined as admin role permissions
> are.
>
> Thanks in advance,
> Glaucimar Aguiar
>
>
>
> -Original Message-
> From: openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.net[mailto:
> openstack-bounces+glaucimar.aguiar=hp@lists.launchpad.net] On Behalf
> Of Aguiar, Glaucimar (Brazil R&D-ECL)
> Sent: terça-feira, 12 de março de 2013 10:34
> To: openstack@lists.launchpad.net
> Subject: [Openstack] Keystone - Domain admin role policies?
>
> Hi,
>
> While studying keystone v3 and domains feature, I realized that current
> policy.json file has no domain_admin role as I was expecting. I wonder if
> this role will be defined in Grizzly timeframe or how do you envision
> domain_admin role enforcement.
>
> Thanks in advance!
> Glaucimar Aguiar
>
>
>
>
> ___
> 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

Re: [Openstack] Keystone V3 Policy Resource Question

[Dolph Mathews]

In designing the API, the goal was to simply store policy.json files (or
any future iterations of it) in any format as a blob in a centralized
location (keystone) that could be retrieved by remote services. While
discussing the design, it spawned a lot of great questions about how to map
policies to services (one policy file per service type? what if you want
different policies in different regions, different domains, or on different
endpoints of the same service?); so, the interface was kept as simple as
possible.

A name attribute was simply not included because it's not applicable to the
current policy.json approach.

There are several proposed blueprints that will force us to think about how
services (and their endpoints), or at least
keystoneclient.middleware.auth_token, are/is aware of their appearance in
keystone's service catalog (attributes like service ID, service type,
region, endpoint ID, endpoint interface, etc):

  https://blueprints.launchpad.net/keystone/+spec/endpoint-filtering

https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-delegation
  https://blueprints.launchpad.net/keystone/+spec/token-scoped-endpoint

The way centralized policies are consumed by other services will be tied
closely into the above conversations & questions. I'm certainly not opposed
to name policies that can be consumed by services simply by name; I think
that's a perfectly simple solution. However, we also need to consider
domain-owned policies and the impact of domain-specific namespacing).

> JSON policies of my own

For OpenStack services or non-OpenStack services?

-Dolph


On Fri, Mar 8, 2013 at 11:49 AM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hello,
>
> ** **
>
> I have been testing  the new Policy APIs and looking at the policy table
> in the Keystone database.  When I consider the OpenStack services including
> Keystone, I find that they all use a policy.json file stored on the file
> system. So my question is how is this new Keystone policy feature
> envisioned to be used? I was thinking of using it to store JSON policies of
> my own, but the only way to GET a policy file is via the UUID which means
> that I have to store it somewhere and keep track of it. Was there a reason
> a human readable tag like “policyName” was not included in this new feature?
> 
>
> ** **
>
> Regards,
>
> ** **
>
> Mark Miller
>
> ___
> 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

Re: [Openstack] Keystone v3 adoption

[Dolph Mathews]

On Thu, Mar 7, 2013 at 2:38 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hello,
>
> ** **
>
> I am sorry but I am still a tad bit confused with this email thread. 
>
> ** **
>
> As of the Grizzly-3 release:
>
> ** **
>
> **1.   **Do Grizzly-3 OpenStack services  like Nova accept and
> validate Keystone V3 tokens (both UUID and PKI) ?
>
It's not their responsibility; it's the responsibility of
keystoneclient.middleware.auth_token which supports both UUID w/ online
validation and PKI w/ offline validation.

> 
>
> **2.   **Do Grizzly-3 OpenStack services use the Keystone v2.0 APIs
> or do they use the Keystone v3 APIs?
>
Horizon is the only core project that uses keystone's non-auth related
API's and will not be updated to consume v3 specific features as of Grizzly
(AFAIK-- someone correct me if I'm wrong).

> 
>
> **3.   **Do the OpenStack services rely upon the keystoneclient? I
> thought the keystoneclient was a command line interface?
>
Indirectly, yes. keystoneclient.middleware.auth_token is deployed in the
pipelines of those services to handle auth. keystoneclient currently
provides command line exposure of v2.0 but we're looking forward to
deprecating these features in favor of a common 'openstack' CLI client. So,
creating a v2.0 tenant today looks like:

  $ keystone tenant-create ...

But given that we're adopting openstackclient and renaming 'tenants' to
'projects', an equivalent command will look like:

  $ openstack project-create ...

> 
>
> ** **
>
> For the Grizzly final release:
>
> ** **
>
> **1.   **Will the Grizzly OpenStack services  like Nova accept and
> validate Keystone V3 tokens (both UUID and PKI) ?
>
There are not essex/folsom/grizzly releases of clients; we're aiming to do
a release of keystoneclient (perhaps v0.3.0) around the time of Grizzly.

> 
>
> **2.   **Will Grizzly OpenStack services use the Keystone v3 APIs?
>
See question 2 above; the answer is not changing between milestone 3 and
final release.

> 
>
> **3.   **Will Grizzly OpenStack services use/implement new v3
> features like “domains” and “groups”?
>
keystoneclient.middleware.auth_token will be providing domain information
to consuming services via the X-Domain-Id / X-Domain-Name headers as it
does for user, project and role data, although no services will be
utilizing that additional data as of Grizzly. Role grants made to v3 groups
will be consumed by all services regardless of whether they're calling the
v2 or v3 API.

> 
>
> **4.   **How will the v3 keystoneclient and the v3 openstackclient be
> used other than as command line interfaces?
>
I'm not sure I understand the question; python-keystoneclient primary
responsibility moving forward will be as a python API, and
python-openstackclient's primary responsibility will be as a CLI
implementation (which happens to consume and expose features from
python-keystoneclient, python-novaclient, python-glanceclient, etc).

> ****
>
> ** **
>
> Regards,
>
> ** **
>
> Mark Miller
>
> ** **
>
> ** **
>
> *From:* openstack-bounces+mark.m.miller=hp@lists.launchpad.net[mailto:
> openstack-bounces+mark.m.miller=hp@lists.launchpad.net] *On Behalf Of
> *Dolph Mathews
> *Sent:* Thursday, March 07, 2013 9:56 AM
> *To:* Aguiar, Glaucimar (Brazil R&D-ECL); openstack
>
> *Subject:* Re: [Openstack] Keystone v3 adoption
>
>  ** **
>
> Yes, exactly. Until keystoneclient.middleware.auth_token is revised, v3
> tokens will basically only be useful against keystone.
>
>
> 
>
> ** **
>
> -Dolph
>
> ** **
>
> On Thu, Mar 7, 2013 at 11:52 AM, Aguiar, Glaucimar (Brazil R&D-ECL) <
> glaucimar.agu...@hp.com> wrote:
>
> Hi Dolph,
>
>  
>
> Thank you very much for your answer. I really appreciate it.
>
>  
>
> Are you saying then, that I configure nova (for example) to use v3
> middleware, I should be able to call nova with a v3 token and this token
> will get validated?
>
>  
>
> Glaucimar Aguiar
>
>  
>
>  
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* quinta-feira, 7 de março de 2013 11:04
> *To:* Aguiar, Glaucimar (Brazil R&D-ECL)
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Keystone v3 adoption
>
>  
>
> The v3 API is largely abstracted from other services (horizon being a
> major exception) using keystoneclient.middleware.auth_token, which is being
> revised here [1] and here [2].
>
>  
>
> Because the c

Re: [Openstack] Keystone v3 adoption

[Dolph Mathews]

Yes, exactly. Until keystoneclient.middleware.auth_token is revised, v3
tokens will basically only be useful against keystone.


-Dolph


On Thu, Mar 7, 2013 at 11:52 AM, Aguiar, Glaucimar (Brazil R&D-ECL) <
glaucimar.agu...@hp.com> wrote:

>  Hi Dolph,
>
> ** **
>
> Thank you very much for your answer. I really appreciate it.
>
> ** **
>
> Are you saying then, that I configure nova (for example) to use v3
> middleware, I should be able to call nova with a v3 token and this token
> will get validated?
>
> ** **
>
> Glaucimar Aguiar
>
> ** **
>
> ** **
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* quinta-feira, 7 de março de 2013 11:04
> *To:* Aguiar, Glaucimar (Brazil R&D-ECL)
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Keystone v3 adoption
>
> ** **
>
> The v3 API is largely abstracted from other services (horizon being a
> major exception) using keystoneclient.middleware.auth_token, which is being
> revised here [1] and here [2].
>
> ** **
>
> Because the clients do not necessarily follow the same release schedule as
> the services, we've obviously been focused on the API and it's server-side
> implementation. I expect we'll do a v3-compliant release of keystoneclient
> around the time of grizzly's release. openstackclient (providing CLI
> exposure) is in the works as well [3].
>
>
> [1]: https://review.openstack.org/#/c/23401/
>
> [2]: https://review.openstack.org/#/c/21942/
>
> [3]:
> https://review.openstack.org/#/q/project:openstack/python-openstackclient+status:open,n,z
> 
>
>
> 
>
> ** **
>
> -Dolph
>
> ** **
>
> On Thu, Mar 7, 2013 at 5:30 AM, Aguiar, Glaucimar (Brazil R&D-ECL) <
> glaucimar.agu...@hp.com> wrote:
>
> Hello,
>
> I would like to know the plans for nova, glance, etc to adopt keystone v3
> API. Is there an expectation that this happens in Havana timeframe?
>
> I am asking as the it seems the Domains feature is not useful until
> services are capable of validating a v3 token and move to keystone v3 API.
>
> Thanks in advance,
>
> Glaucimar Aguiar
>
>
>
> ___
> 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

Re: [Openstack] Keystone v3 adoption

[Dolph Mathews]

The v3 API is largely abstracted from other services (horizon being a major
exception) using keystoneclient.middleware.auth_token, which is being
revised here [1] and here [2].

Because the clients do not necessarily follow the same release schedule as
the services, we've obviously been focused on the API and it's server-side
implementation. I expect we'll do a v3-compliant release of keystoneclient
around the time of grizzly's release. openstackclient (providing CLI
exposure) is in the works as well [3].

[1]: https://review.openstack.org/#/c/23401/
[2]: https://review.openstack.org/#/c/21942/
[3]:
https://review.openstack.org/#/q/project:openstack/python-openstackclient+status:open,n,z


-Dolph


On Thu, Mar 7, 2013 at 5:30 AM, Aguiar, Glaucimar (Brazil R&D-ECL) <
glaucimar.agu...@hp.com> wrote:

> Hello,
>
> I would like to know the plans for nova, glance, etc to adopt keystone v3
> API. Is there an expectation that this happens in Havana timeframe?
>
> I am asking as the it seems the Domains feature is not useful until
> services are capable of validating a v3 token and move to keystone v3 API.
>
> Thanks in advance,
>
> Glaucimar Aguiar
>
>
>
> ___
> 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

Re: [Openstack] Possible keystone/common/controller.py Token Bug

[Dolph Mathews]

This appears to be a valid bug -- we were concerned with v2-v3
token interop when v3 auth merged, but I thought we had ironed out the
kinks (we have several related tests in tests/test_v3_auth.py for this
reason). I targeted the bug at RC1 as we need to have this fixed for v3 to
be useful in grizzly.



-Dolph


On Tue, Mar 5, 2013 at 3:18 PM, Christopher Armstrong <
christopher.armstr...@canonical.com> wrote:

> So I've filed a bug on launchpad[1] about the issue discussed in the
> thread[2] with this subject (sorry, I subscribed after the message went
> out, so this message isn't properly threaded).
>
> Is it really legit? The discussion stopped abruptly. It seems like a
> pretty major bug; I can't do much with the API right now because of it (I
> think).
>
> [1] 
> https://bugs.launchpad.net/**keystone/+bug/1145541
>
> [2] 
> https://lists.launchpad.net/**openstack/msg21458.html
>
> -radix
>
>
> __**_
> 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

Re: [Openstack] keystone-manage db_sync failures

[Dolph Mathews]

I didn't have any problem import 'exceptions' from sqlalchemy 0.7.8; are
you sure you didn't end up with a different version installed after
"re-installing the whole thing from scratch"?

  $ python -c "import sqlalchemy; print sqlalchemy.__version__; from
sqlalchemy import exceptions; print exceptions"
  0.7.8
  


-Dolph


On Tue, Mar 5, 2013 at 8:49 PM, Wyllys Ingersoll <
wyllys.ingers...@evault.com> wrote:

>
>
> I saw that bug, but that was not the problem because I had the right
> versions of all of those pieces.
>
> The problem arose when I had to change the IP addr of my host.  I updated
> all of the config files and the endpoints in the keystone DB, but still
> nova was pulling the old IP addr from somewhere, but I could not figure out
> where it was coming from.  It wasn't in the DB and it wasn't in any of the
> config files.  I finally gave up and re-installed the whole thing from
> scratch.  Luckily, it was in a VM that I was using for testing so I didn't
> lose any real data or anything and the re-install was quick and smooth.
>
> I still have no idea what went wrong and my lasting impression is that the
> whole thing is a house of cards that is still very fragile to the slightest
> inconsistencies.
>
> -Wyllys
>
>
> On Mar 5, 2013, at 9:42 PM, Lei Zhang  wrote:
>
> see https://bugs.launchpad.net/keystone/+bug/1073569 bug
>
>
> On Wed, Mar 6, 2013 at 2:18 AM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)  wrote:
>
>> Try adding the config file name to the command line:
>>
>> > keystone-manage --config-file /etc/keystone/keystone.conf
>> db_sync
>>
>> Mark
>>
>> -Original Message-
>> From: openstack-bounces+mark.m.miller=hp@lists.launchpad.net [mailto:
>> openstack-bounces+mark.m.miller=hp@lists.launchpad.net] On Behalf Of
>> Wyllys Ingersoll
>> Sent: Tuesday, March 05, 2013 8:27 AM
>> To: openstack@lists.launchpad.net
>> Subject: [Openstack] keystone-manage db_sync failures
>>
>> I keep getting a failure when trying to configure keystone.
>>  keystone-manage seems to have issues with sqlalchemy.
>>
>> Here are my versions:
>>
>> python-keystoneclient: 1:0.1.3-0ubuntu1.1~cloud0
>> python-sqlalchemy:  0.7.8-1ubuntu1~cloud0
>> python-migrate:  0.7.2-1ubuntu1
>>
>> Any ideas??
>>
>> $ keystone-manage db_sync
>> Traceback (most recent call last):
>>   File "/usr/bin/keystone-manage", line 28, in 
>> cli.main(argv=sys.argv, config_files=config_files)
>>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 164, in
>> main
>> return run(cmd, (args[:1] + args[2:]))
>>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 147, in
>> run
>> return CMDS[cmd](argv=args).run()
>>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 35, in run
>> return self.main()
>>   File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 54, in
>> main
>> driver = importutils.import_object(getattr(CONF, k).driver)
>>   File
>> "/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py",
>> line 40, in import_object
>> return import_class(import_str)(*args, **kwargs)
>>   File
>> "/usr/lib/python2.7/dist-packages/keystone/openstack/common/importutils.py",
>> line 30, in import_class
>> __import__(mod_str)
>>   File
>> "/usr/lib/python2.7/dist-packages/keystone/identity/backends/sql.py", line
>> 22, in 
>> from keystone.common.sql import migration
>>   File
>> "/usr/lib/python2.7/dist-packages/keystone/common/sql/migration.py", line
>> 23, in 
>> from migrate.versioning import api as versioning_api
>>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line
>> 33, in 
>> from migrate.versioning import (repository, schema, version,
>>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py",
>> line 10, in 
>> from sqlalchemy import exceptions as sa_exceptions
>> ImportError: cannot import name exceptions
>>
>>
>> ___
>> 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
>>
>
>
>
> --
> Lei Zhang
>
> Blog: http://jeffrey4l.github.com
> twitter/weibo: @jeffrey4l
>
>
>
> ___
> 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/

Re: [Openstack] Fun with OpenStack Grizzly install...

[Dolph Mathews]

On Tue, Mar 5, 2013 at 5:28 PM, Brad Knowles wrote:

> On Mar 5, 2013, at 5:20 PM, Matt Joyce 
> wrote:
>
> > check in horizon and see if you can follow inside of a stack trace
> there.  you can see if any of the context's from the wsgi queries is seeing
> a 404.
>
> Horizon?  That's not a service I've heard of before.  I'm basically
> following the structure at <
> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installinggrizzlyubuntuprecise.html>
> for initial installation, and I've gotten hung on the glance part at <
> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/osfolubuntu-imageservice.html
> >.
>
> > these would be queries between glance and other backend APIs.
> >
> > example:
> >
> > you ---  query >  glance
> >
> > glance sees you token...
> >
> > glance --- query -> keystone
> >
> > if that query from glance to keystone fails...  it will report a 404.
>  BUT that won't necessarily show up in logs as you'd expect since it's a
> backend query.
>
> The query from glance to keystone appears to be okay -- I'm seeing 200
> status responses in the keystone.log.
>
> > related idea:
> >
> > verify that your catalog service is pointing to the right API endpoints
> on keystone.
>
> Catalog service?  That's another name that I have not heard of before, at
> least not in the context of OpenStack.
>

The "service catalog" refers to a subset of keystone's interface that
provides a catalog of services and endpoints to authenticated API users.
It's the computed result of your service-list and endpoint-list and it's
how those users find all the other OpenStack services, like nova and glance.

In your case, all or most of your endpoints are wrong (they all contain
/v2/ which I'm not sure is correct for any service?), so `glance index`
probably can't find glance at all. I generally refer to keystone's
sample_data.sh script for a generally idea of what the endpoints should
look like:

  https://github.com/openstack/keystone/blob/master/tools/sample_data.sh


> --
> Brad Knowles 
> Senior Consultant
>
>
> ___
> 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

Re: [Openstack] keystone help! keystone stop/waiting

[Dolph Mathews]

Just opened a bug to track the public_port string vs integer issue, with a
fix in review:

  https://bugs.launchpad.net/bugs/1147842


-Dolph


On Tue, Mar 5, 2013 at 3:28 PM, Brad Knowles wrote:

> On Mar 5, 2013, at 3:21 PM, "Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)" 
>  wrote:
>
> > You aren't alone. I am just glad for this email group to ask questions.
>
> Me too!
>
> > Now change the "d/" to "s/" in the following lines in keystone.conf.
> >
> > # The base endpoint URLs for keystone that are advertised to clients
> > # (NOTE: this does NOT affect how keystone listens for connections)
> > public_endpoint = http://localhost:%(public_port)s/
> > admin_endpoint = http://localhost:%(admin_port)s/
>
> Yup, that fixed the crash.  I guess now I get to contribute this change
> back to the project.
>
> That, and debugging the next issue.  ;-)
>
> --
> Brad Knowles 
> Senior Consultant
>
>
> ___
> 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

Re: [Openstack] Help with keystone LDAP backend

[Dolph Mathews]

On that note, I very much like how docs.python.org does it, where not only
is the current page's version prominently specified at the top of the page,
but it also serves as an easy way to switch to another version of the docs,
e.g.: http://docs.python.org/2/tutorial/


-Dolph


On Mon, Mar 4, 2013 at 4:40 PM, Steven Presser  wrote:

>  Anne,
> Yes that would.  What I think might be a better revision is putting
> the version somewhere prominently on the page (say, the upper right hand
> corner, above "").
>
> Steve
>
>
> On 03/04/2013 05:26 PM, Anne Gentle wrote:
>
> I've been wondering whether we should have docs.openstack.org/master/ to
> match expectations, would that have helped in your case? Thanks for
> clarifying.
>
> Anne
>
>
> On Mon, Mar 4, 2013 at 4:22 PM, Steven Presser  wrote:
>
>>  Apparently the trunk docs.  I could have sworn that wasn't what I
>> bookmarked.  In any case, maybe explicitly marking trunk docs as
>> newer-than-latest would help?
>>
>> (
>> http://docs.openstack.org/trunk/openstack-compute/admin/content/reference-for-ldap-config-options.html)
>>
>>
>>
>> On 03/04/2013 05:09 PM, Dolph Mathews wrote:
>>
>> Yes, this feature just landed during grizzly-m3.
>>
>>  Which docs are you referring to? The variable wasn't included in
>> folsom's etc/keystone.conf.sample, for example.
>>
>>
>>  -Dolph
>>
>>
>> On Mon, Mar 4, 2013 at 3:35 PM, Steven Presser  wrote:
>>
>>>  The answer would appear to be that this flag doesn't do anything in the
>>> Folsom release.  Apprently this was fixed by:
>>> https://bugs.launchpad.net/keystone/+bug/1122181
>>>
>>> Unless I'm misreading something.  Could we perhaps update the docs to
>>> reflect the fact that this isn't available in releases yet?
>>>
>>>
>>> On 03/04/2013 04:08 PM, Steven Presser wrote:
>>>
>>> This is what came out of my logs.  I've bolded what looks relevant to me:
>>>
>>> LDAP init: url=ldap://typhon.acm.jhu.edu
>>> 2013-03-04 16:06:01DEBUG [keystone.common.ldap.core] LDAP bind:
>>> dn=cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
>>> 2013-03-04 16:06:01DEBUG [keystone.common.ldap.core] LDAP search:
>>> dn=ou=Users,ou=OpenStack,dc=acm,dc=jhu,dc=edu, *scope=1*,
>>> query=(objectClass=inetOrgPerson)
>>>
>>> Unless I'm reading that very wrong, my scope search request is being
>>> ignored.  Time to dive into the code, I suppose.
>>>
>>> Steve
>>>
>>> On 03/04/2013 10:15 AM, Dolph Mathews wrote:
>>>
>>> I'd suggest enabling debug=True in keystone.conf and comparing the LDAP
>>> queries being issued (shown in logs) against what you're expecting.
>>>
>>>  I believe that [ldap] query_scope=sub does in fact expand queries to
>>> apply to subtrees, beyond just a single level (as the default value is
>>> query_scope=one).
>>>
>>>
>>>  -Dolph
>>>
>>>
>>> On Sun, Mar 3, 2013 at 12:05 PM, Steven Presser wrote:
>>>
>>>> Hey all,
>>>> I have some questions about using the LDAP backend for keystone.
>>>>  I'm in what seems to be an odd situation.  I have an organization-wide
>>>> DLAP directory that already exists.  All of our users will have access to
>>>> OpenStack, so we want to tie directly into this directory.  However, we
>>>> can't have service accounts mixed in with the regular users, at least not
>>>> in any way that might result in you being able to log in to a service
>>>> account.  For neatness, the directory admin would prefer that all the
>>>> OpenStack stuff be off in its own OU (and has allocated us one so we can do
>>>> that).
>>>> In that OU, I've set up the recommended schema from
>>>> http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-keystone-for-ldap-backend.html(changing
>>>>  it to my domain, obviously).  I then aliased all our users in to
>>>> ou=Users.  The relevant part of my keystone.conf currently looks like:
>>>>
>>>> [ldap]
>>>> url = ldap://[host]
>>>> user = cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
>>>> password = [password]
>>>> suffix = dc=acm,dc=jhu,dc=edu
>>>> use_dumb_member = False
>>>> allow_subtree_delete = False
>>>> query_scope = sub
>>>>
>>>> As nea

Re: [Openstack] Help with keystone LDAP backend

[Dolph Mathews]

Yes, this feature just landed during grizzly-m3.

Which docs are you referring to? The variable wasn't included in folsom's
etc/keystone.conf.sample, for example.


-Dolph


On Mon, Mar 4, 2013 at 3:35 PM, Steven Presser  wrote:

>  The answer would appear to be that this flag doesn't do anything in the
> Folsom release.  Apprently this was fixed by:
> https://bugs.launchpad.net/keystone/+bug/1122181
>
> Unless I'm misreading something.  Could we perhaps update the docs to
> reflect the fact that this isn't available in releases yet?
>
>
> On 03/04/2013 04:08 PM, Steven Presser wrote:
>
> This is what came out of my logs.  I've bolded what looks relevant to me:
>
> LDAP init: url=ldap://typhon.acm.jhu.edu
> 2013-03-04 16:06:01DEBUG [keystone.common.ldap.core] LDAP bind:
> dn=cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
> 2013-03-04 16:06:01DEBUG [keystone.common.ldap.core] LDAP search:
> dn=ou=Users,ou=OpenStack,dc=acm,dc=jhu,dc=edu, *scope=1*,
> query=(objectClass=inetOrgPerson)
>
> Unless I'm reading that very wrong, my scope search request is being
> ignored.  Time to dive into the code, I suppose.
>
> Steve
>
> On 03/04/2013 10:15 AM, Dolph Mathews wrote:
>
> I'd suggest enabling debug=True in keystone.conf and comparing the LDAP
> queries being issued (shown in logs) against what you're expecting.
>
>  I believe that [ldap] query_scope=sub does in fact expand queries to
> apply to subtrees, beyond just a single level (as the default value is
> query_scope=one).
>
>
>  -Dolph
>
>
> On Sun, Mar 3, 2013 at 12:05 PM, Steven Presser  wrote:
>
>> Hey all,
>> I have some questions about using the LDAP backend for keystone.  I'm
>> in what seems to be an odd situation.  I have an organization-wide DLAP
>> directory that already exists.  All of our users will have access to
>> OpenStack, so we want to tie directly into this directory.  However, we
>> can't have service accounts mixed in with the regular users, at least not
>> in any way that might result in you being able to log in to a service
>> account.  For neatness, the directory admin would prefer that all the
>> OpenStack stuff be off in its own OU (and has allocated us one so we can do
>> that).
>> In that OU, I've set up the recommended schema from
>> http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-keystone-for-ldap-backend.html(changing
>>  it to my domain, obviously).  I then aliased all our users in to
>> ou=Users.  The relevant part of my keystone.conf currently looks like:
>>
>> [ldap]
>> url = ldap://[host]
>> user = cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
>> password = [password]
>> suffix = dc=acm,dc=jhu,dc=edu
>> use_dumb_member = False
>> allow_subtree_delete = False
>> query_scope = sub
>>
>> As near as I can tell, this should correspond to this query:
>> $ ldapsearch -x  -D cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu -w
>> [password]  -b dc=acm,dc=jhu,dc=edu '(objectclass=inetOrgPerson)' -s sub
>>
>> Which returns my aliased users correctly.  (that is, it returns "dn:
>> uid=[uid],ou=People,dc=acm,dc=jhu,dc=edu" for each user).
>>
>> I really can't figure out whats going on here.  Logically, this should
>> work, but (obviously) doesn't.  Anyone have some advice for me?   My
>> suspicion is that query_scope=sub isn't doing what I expect.  (Returning
>> search results from within a subtree)
>>
>> Oh, finally, I have DEREF always enabled in ldap.conf.
>>
>> Thanks,
>> Steve
>>
>>
>>
>> ___
>> 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
>
>
___
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] Authorization Question

[Dolph Mathews]

That's correct. Right now, all endpoints registered in keystone are
returned to all users, regardless of whether they actually have any sort of
authorization on those endpoints.

I suspect we'll be having a planning session at the design summit on this
topic -- I'd be helpful to better understand your ideal use case in
suppressing endpoints from the catalog? In Grizzly, users, groups,
projects, and domains have absolutely no relationship with services and
endpoints within keystone. That becomes deployment specific when you
consider how RBAC is applied service-side with policy.json, etc, but those
services are not necessarily aware of how they appear in the service
catalog, nor does keystone interpret policy files other than it's own.


-Dolph


On Mon, Mar 4, 2013 at 2:32 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hello,
>
> ** **
>
> I have been looking over the Keystone v3 API documentation as well as the
> database table columns. My question concerns endpoint access restrictions.
> I don’t see any noticeable way to associate endpoints with domains which
> means that any user can access any endpoint of any domain. Is this correct?
> The only database column that might come into play is the region column of
> the endpoint table.
>
> ** **
>
> Regards,
>
> ** **
>
> Mark Miller
>
> ___
> 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

Re: [Openstack] Help with keystone LDAP backend

[Dolph Mathews]

I'd suggest enabling debug=True in keystone.conf and comparing the LDAP
queries being issued (shown in logs) against what you're expecting.

I believe that [ldap] query_scope=sub does in fact expand queries to apply
to subtrees, beyond just a single level (as the default value is
query_scope=one).


-Dolph


On Sun, Mar 3, 2013 at 12:05 PM, Steven Presser  wrote:

> Hey all,
> I have some questions about using the LDAP backend for keystone.  I'm
> in what seems to be an odd situation.  I have an organization-wide DLAP
> directory that already exists.  All of our users will have access to
> OpenStack, so we want to tie directly into this directory.  However, we
> can't have service accounts mixed in with the regular users, at least not
> in any way that might result in you being able to log in to a service
> account.  For neatness, the directory admin would prefer that all the
> OpenStack stuff be off in its own OU (and has allocated us one so we can do
> that).
> In that OU, I've set up the recommended schema from
> http://docs.openstack.org/**trunk/openstack-compute/admin/**
> content/configuring-keystone-**for-ldap-backend.html(changing
>  it to my domain, obviously).  I then aliased all our users in to
> ou=Users.  The relevant part of my keystone.conf currently looks like:
>
> [ldap]
> url = ldap://[host]
> user = cn=admin,ou=OpenStack,dc=acm,**dc=jhu,dc=edu
> password = [password]
> suffix = dc=acm,dc=jhu,dc=edu
> use_dumb_member = False
> allow_subtree_delete = False
> query_scope = sub
>
> As near as I can tell, this should correspond to this query:
> $ ldapsearch -x  -D cn=admin,ou=OpenStack,dc=acm,**dc=jhu,dc=edu -w
> [password]  -b dc=acm,dc=jhu,dc=edu '(objectclass=inetOrgPerson)' -s sub
>
> Which returns my aliased users correctly.  (that is, it returns "dn:
> uid=[uid],ou=People,dc=acm,dc=**jhu,dc=edu" for each user).
>
> I really can't figure out whats going on here.  Logically, this should
> work, but (obviously) doesn't.  Anyone have some advice for me?   My
> suspicion is that query_scope=sub isn't doing what I expect.  (Returning
> search results from within a subtree)
>
> Oh, finally, I have DEREF always enabled in ldap.conf.
>
> Thanks,
> Steve
>
>
>
> __**_
> 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

Re: [Openstack] Possible keystone/common/controller.py Token Bug

[Dolph Mathews]

Looks like a valid bug to me -- this code just merged a week ago.

How did you create the token? I'm guessing it was generated by v2 and
utilized here on v3?


-Dolph


On Fri, Mar 1, 2013 at 5:03 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hello,
>
> ** **
>
> In trying to understand the Keystone Grizzly-3 release, I decided to add a
> service via a REST API call using an admin user’s token instead of the
> admin token found in keystone.conf. When I do I get error:
>
> ** **
>
> ** **
>
> Traceback (most recent call last):
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/common/wsgi.py",
> line 231, in __call__
>
> result = method(context, **params)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/common/controller.py",
> line 66, in wrapper
>
> context, kwargs)
>
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/common/controller.py",
> line 32, in _build_policy_check_credentials
>
> token_data = token_ref['token_data']
>
> KeyError: 'token_data'
>
> (access): 2013-03-01 13:53:26,754 INFO 15.253.58.148 - -
> [01/Mar/2013:21:53:26 +] "POST 
> http://15.253.58.165:35357/v3/servicesHTTP/1.0"; 500 156
> 
>
> (eventlet.wsgi.server): 2013-03-01 13:53:26,755 DEBUG 15.253.58.148 - -
> [01/Mar/2013 13:53:26] "POST /v3/services HTTP/1.1" 500 328 0.020434
>
> ** **
>
> ** **
>
> When I change line 32 in the file from “token_data =
> token_ref['token_data']” to “token_data = token_ref”, the code appears to
> work.
>
> ** **
>
> ** **
>
> def _build_policy_check_credentials(self, action, context, kwargs):
>
> ** **
>
> LOG.debug(_('RBAC: Authorizing %s(%s)') % (
>
> action,
>
> ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])))
>
> ** **
>
> try:
>
> token_ref = self.token_api.get_token(
>
> context=context, token_id=context['token_id'])
>
> except exception.TokenNotFound:
>
> LOG.warning(_('RBAC: Invalid token'))
>
> raise exception.Unauthorized()
>
> ** **
>
> creds = {}
>
> ** **
>
> #   token_data = token_ref['token_data']
>
> token_data = token_ref
>
> ** **
>
> ** **
>
> So my question is do I need to have “token_data” in the token table
> somehow or is this a code bug?
>
> ** **
>
> Regards,
>
>
> Mark Miller
>
> ___
> 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

Re: [Openstack] Are the Python APIs public or internal?

[Dolph Mathews]

+1; keystoneclient is not deprecated nor has openstackclient been abandoned.

The responsibility of implementing a CLI is simply being handed off to
openstackclient. Using 'keystone' on the CLI will therefore be deprecated
at some point in favor of using 'openstack'.

-Dolph


On Fri, Mar 1, 2013 at 11:58 AM, Dean Troyer  wrote:

> On Fri, Mar 1, 2013 at 11:50 AM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)  wrote:
> > I have a question about the keystone client. You just mentioned
> > keystoneclient.v3. I was under the impression that the keystone client
> was
> > going to be deprecated and replaced by the openstackclient. However,
> when I
> > checked yesterday I noticed that the openstackclient was listed as
> > “abandoned”. Are you saying that an updated version of the keystoneclient
> > will shortly be made available for V3? If so, would you please post the
> URL
> > for the project?
>
> Where is openstackclient marked abandoned?  It is still under
> development, albiet at a slower pace than I'd like.  It is meant to be
> a single CLI for OpenStack that leverages the libraries provided by
> the individual project clients. So it uses the keystoneclient python
> libs but not the cli/shell bits.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.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

Re: [Openstack] Keystone Grizzly-3 Tokens not getting saved to database

[Dolph Mathews]

Your keystone.log should have a more complete backtrace of the error -- can
you post that?

As for your token table being empty, are you sure you're using the SQL
driver (keystone.token.backends.sql.Token)? I believe the default driver is
in-memory (keystone.token.backends.kvs.Token). The token table will be
created by db_sync regardless of which driver is configured.


-Dolph


On Thu, Feb 28, 2013 at 5:23 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hello,
>
> ** **
>
> I have some tests that attempt to retrieve tenants/projects from Keystone
> using an admin user’s token. The test gave the following error:
>
> ** **
>
> {"error": {"message": "coercing to Unicode: need string or buffer,
> NoneType found", "code": 400, "title": "Bad Request"}}
>
> ** **
>
> The same code works fine if I use the X-Auth-Token from the keystone.conf
> file. I checked the database to look at the tokens and found that the
> “token” table is empty. Does anyone have any ideas as to why tokens are not
> getting stored on my system? I assume it is some keystone.conf parameter,
> but I really do not know.
>
> ** **
>
> Regards,
>
> ** **
>
> Mark
>
> ___
> 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

Re: [Openstack] Error while executing sample_data.sh script

[Dolph Mathews]

The 409 Conflicts are indicating that what the script is trying to create
already exists (role names must be unique for example). If you've run the
same commands manually before, they'll fail on a subsequent attempt
(reproducible by simply running the script twice).


-Dolph


On Fri, Mar 1, 2013 at 1:44 AM, Ashutosh Narayan  wrote:

> Hi Swapnil, Atul
>
> Reading document helps. I have done these steps manually before and
> was again going ahead to run the script for the same. That's why I got
> so many error messages. Looks like problem is solved. I get the
> desired output.
>
>
> On Fri, Mar 1, 2013 at 12:39 PM, Swapnil Kulkarni <
> swapnilkulkarni2...@gmail.com> wrote:
>
>> I agree with Atul, if you go through documentation you will find where to
>> change the passwords required by keystone commands.
>>
>> Cheers :)
>> On Mar 1, 2013 12:22 PM, "Atul Jha"  wrote:
>>
>>>  Ashutosh,
>>>
>>> my suggestion would be go through the documentation try to understandwhat 
>>> each keystone command is doing. Just running a script and mailing to
>>> list for everything is not a good idea.
>>>
>>> Spend sometime with document, understand key concepts. just a su
>>> ggestion.
>>>
>>>  --
>>> *From:* 
>>> openstack-bounces+atul.jha=csscorp@lists.launchpad.net[openstack-bounces+atul.jha=
>>> csscorp@lists.launchpad.net] on behalf of Ashutosh Narayan [
>>> aashutoshnara...@gmail.com]
>>> *Sent:* Friday, March 01, 2013 12:14 PM
>>> *To:* OpenStack
>>> *Subject:* [Openstack] Error while executing sample_data.sh script
>>>
>>>   Hi folks,
>>>
>>>  When I run the sample_data.sh script mentioned at the 
>>> link
>>>  I
>>> get the following errors :
>>>
>>>  Conflict occurred attempting to store user. (IntegrityError) (1062,
>>> "Duplicate entry 'admin' for key 'name'") (HTTP 409)
>>> Conflict occurred attempting to store role. (IntegrityError) (1062,
>>> "Duplicate entry 'admin' for key 'name'") (HTTP 409)
>>> usage: keystone user-role-add --user-id  --role-id 
>>>   [--tenant-id ]
>>> keystone user-role-add: error: argument --user-id/--user_id: expected
>>> one argument
>>> Conflict occurred attempting to store tenant. (IntegrityError) (1062,
>>> "Duplicate entry 'service' for key 'name'") (HTTP 409)
>>> Conflict occurred attempting to store user. (IntegrityError) (1062,
>>> "Duplicate entry 'glance' for key 'name'") (HTTP 409)
>>> usage: keystone user-role-add --user-id  --role-id 
>>>   [--tenant-id ]
>>> keystone user-role-add: error: argument --user-id/--user_id: expected
>>> one argument
>>> usage: keystone user-create --name  [--tenant-id ]
>>> [--pass ] [--email ]
>>> [--enabled ]
>>> keystone user-create: error: argument --tenant-id: expected one argument
>>> usage: keystone user-role-add --user-id  --role-id 
>>>   [--tenant-id ]
>>> keystone user-role-add: error: argument --user-id/--user_id: expected
>>> one argument
>>> usage: keystone user-create --name  [--tenant-id ]
>>> [--pass ] [--email ]
>>> [--enabled ]
>>> keystone user-create: error: argument --tenant-id: expected one argument
>>> usage: keystone user-role-add --user-id  --role-id 
>>>   [--tenant-id ]
>>> keystone user-role-add: error: argument --user-id/--user_id: expected
>>> one argument
>>> usage: keystone user-create --name  [--tenant-id ]
>>> [--pass ] [--email ]
>>> [--enabled ]
>>> keystone user-create: error: argument --tenant-id: expected one argument
>>> usage: keystone user-role-add --user-id  --role-id 
>>>   [--tenant-id ]
>>> keystone user-role-add: error: argument --user-id/--user_id: expected
>>> one argument
>>> +-+---+
>>> |   Property  | Value |
>>> +-+---+
>>> |   adminurl  |  http://localhost:$(admin_port)s/v2.0 |
>>> |  id |626ff3533c7e452e8850a94e4d30309f   |
>>> | internalurl | http://localhost:$(public_port)s/v2.0 |
>>> |  publicurl  | http://localhost:$(public_port)s/v2.0 |
>>> |region   |   RegionOne   |
>>> |  service_id |1fe65f54d1714d369f7b8975de89d41d   |
>>> +-+---+
>>> +-+--+
>>> |   Property  |Value |
>>> +-+--+
>>> |   adminurl  | http://localhost:$(compute_port)s/v1.1/$(tenant_id)s |
>>> |  id |   64206e8f1b6148a0b63870c5fd333887   |
>>> | internalurl | http://local

Re: [Openstack] Are the Python APIs public or internal?

[Dolph Mathews]

I believe they should certainly be treated as public API's -- just like any
other library. I'd also treat them as stable if they've ever been included
in a versioned release. That said, I'm sure it would be easy to find
examples of methods & attributes within the library that are not intended
to be consumed externally, but perhaps either the naming convention or
documentation doesn't sufficiently indicate that.

In keysoneclient, we're making backwards incompatible changes in a new
subpackage (keystoneclient.v3) while maintaing compatibility in the common
client code. For example, you should always be able to initialize the
client with a tenant_id / tenant_name, even though the client will soon be
using project_id / project_name internally to reflect our revised lingo.


-Dolph


On Thu, Feb 28, 2013 at 11:07 PM, Lorin Hochstein
wrote:

> Here's an issue that came up in the operators doc sprint this week.
>
> Let's say I wanted to write some Python scripts using the APIs exposed
> by the python-*client packages. As a concrete example, let's say I wrote a
> script that uses the keystone Python API that's exposed in the
> python-keystoneclient package:
>
>
> https://github.com/lorin/openstack-ansible/blob/master/playbooks/keystone/files/keystone-init.py
>
> Are these APIs "public" or "stable"  in some meaningful way? (i.e., can I
> count on this script still working across minor release upgrades)? Or
> should they be treated like "internal" APIs that could be changed at any
> time in the future? Or is this not defined at all?
>
> Lorin
>
>
> ___
> 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

Re: [Openstack] [Keystone] service unavailable

[Dolph Mathews]

I'm not aware that keystone is capable of raising a 503 Service
Unavailable... are you running through a proxy? If so, I assume there's an
issue with it's configuration.


-Dolph


On Wed, Feb 27, 2013 at 8:27 AM, Tomáš Šoltys wrote:

> Hi,
>
> Yes, the service is running and listening. I can see it via ps as well as
> by using netstat
>
> Here is my keystone.conf
>
>
> -
> [DEFAULT]
> log_file = /var/log/keystone/keystone.log
> admin_token = 012345SECRET99TOKEN012345
>
> [sql]
> connection = mysql://keystone:12345678@localhost/keystone
>
> [identity]
> driver = keystone.identity.backends.sql.Identity
>
> [catalog]
> template_file = /etc/keystone/default_catalog.templates
> driver = keystone.catalog.backends.sql.Catalog
>
> [token]
> driver = keystone.token.backends.sql.Token
>
> [policy]
>
> [ec2]
> driver = keystone.contrib.ec2.backends.sql.Ec2
>
> [ssl]
>
> [signing]
>
> [ldap]
>
> [filter:debug]
> paste.filter_factory = keystone.common.wsgi:Debug.factory
>
> [filter:token_auth]
> paste.filter_factory = keystone.middleware:TokenAuthMiddleware.factory
>
> [filter:admin_token_auth]
> paste.filter_factory = keystone.middleware:AdminTokenAuthMiddleware.factory
>
> [filter:xml_body]
> paste.filter_factory = keystone.middleware:XmlBodyMiddleware.factory
>
> [filter:json_body]
> paste.filter_factory = keystone.middleware:JsonBodyMiddleware.factory
>
> [filter:user_crud_extension]
> paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory
>
> [filter:crud_extension]
> paste.filter_factory = keystone.contrib.admin_crud:CrudExtension.factory
>
> [filter:ec2_extension]
> paste.filter_factory = keystone.contrib.ec2:Ec2Extension.factory
>
> [filter:s3_extension]
> paste.filter_factory = keystone.contrib.s3:S3Extension.factory
>
> [filter:url_normalize]
> paste.filter_factory = keystone.middleware:NormalizingFilter.factory
>
> [filter:stats_monitoring]
> paste.filter_factory = keystone.contrib.stats:StatsMiddleware.factory
>
> [filter:stats_reporting]
> paste.filter_factory = keystone.contrib.stats:StatsExtension.factory
>
> [app:public_service]
> paste.app_factory = keystone.service:public_app_factory
>
> [app:admin_service]
> paste.app_factory = keystone.service:admin_app_factory
>
> [pipeline:public_api]
> pipeline = stats_monitoring url_normalize token_auth admin_token_auth
> xml_body json_body debug ec2_extension user_crud_extension public_service
>
> [pipeline:admin_api]
> pipeline = stats_monitoring url_normalize token_auth admin_token_auth
> xml_body json_body debug stats_reporting ec2_extension s3_extension
> crud_extension admin_service
>
> [app:public_version_service]
> paste.app_factory = keystone.service:public_version_app_factory
>
> [app:admin_version_service]
> paste.app_factory = keystone.service:admin_version_app_factory
>
> [pipeline:public_version_api]
> pipeline = stats_monitoring url_normalize xml_body public_version_service
>
> [pipeline:admin_version_api]
> pipeline = stats_monitoring url_normalize xml_body admin_version_service
>
> [composite:main]
> use = egg:Paste#urlmap
> /v2.0 = public_api
> / = public_version_api
>
> [composite:admin]
> use = egg:Paste#urlmap
> /v2.0 = admin_api
> / = admin_version_api
>
> -
>
>
> 2013/2/27 Sylvain Bauza 
>
>>  Could you please paste your keystone.conf ?
>> Also, could you please check keystone service is started ?
>>
>> -Sylvain
>>
>> Le 27/02/2013 15:06, Tomáš Šoltys a écrit :
>>
>>  Hi,
>>
>>  I am trying to setup keystone myself on CentOS using this step-by-step
>> instructions:
>>
>> http://docs.openstack.org/essex/openstack-compute/install/yum/content/install-keystone.html
>>
>> I have followed the steps above but when I try to create a tenant I get
>> "Unable to communicate with identity service: (503, 'Service Unavailable').
>> (HTTP 400)"
>>
>> The command I am using is:
>> keystone --os-token 012345SECRET99TOKEN012345 --endpoint
>> http://127.0.0.1:35357/v2.0 tenant-create --name openstackDefault
>> --description "Default tenant"
>>
>> The service is running and listening on port 35357.
>>
>> Am I missing something?
>> Thanks,
>>
>> Tomáš Šoltys
>>
>> tomas.sol...@gmail.com
>> http://www.range-software.com
>> (+420) 776-843-663
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Tom

Re: [Openstack] keystone-manage db_sync ERROR

[Dolph Mathews]

Meant to reply on-list.

-Dolph

On Tue, Feb 26, 2013 at 2:39 PM, Dolph Mathews wrote:

> Thanks for the feedback; cc'ing Adam Young. I raised a bug to track the
> issue: https://bugs.launchpad.net/keystone/+bug/1133608
>
>
> -Dolph
>
>
> On Tue, Feb 26, 2013 at 2:24 PM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)  wrote:
>
>> Hello,
>>
>> I have trying to install Keystone Grizzly-3 and cannot get past the
>> following error. The "keystone-manage db_sync" command is generating the
>> following error. I have tried deleting and re-creating the MySQL database
>> (connection = mysql://keystonedbadmin:password@15.253.59.37/keystone)
>> but the error remains. Has anyone else run into this problem and found a
>> solution? I noticed the role ID value 9fe2ff9ee4384b1894a90878d3e92bab in
>> file
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/config.py".
>>
>>
>> Regards,
>>
>> Mark
>>
>>
>>
>> root@build-HP-Compaq-6005-Pro-SFF-PC:~/keystone-2013.1.g3/keystone-2013.1.g3#
>> keystone-manage db_sync
>> Traceback (most recent call last):
>>   File "/usr/local/bin/keystone-manage", line 5, in 
>> pkg_resources.run_script('keystone==2013.1.g3', 'keystone-manage')
>>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 499, in
>> run_script
>> self.require(requires)[0].run_script(script_name, ns)
>>   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1235, in
>> run_script
>> execfile(script_filename, namespace, namespace)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/EGG-INFO/scripts/keystone-manage",
>> line 28, in 
>> cli.main(argv=sys.argv, config_files=config_files)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/cli.py",
>> line 172, in main
>> CONF.command.cmd_class.main()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/cli.py",
>> line 53, in main
>> driver.db_sync()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/identity/backends/sql.py",
>> line 171, in db_sync
>> migration.db_sync()
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/common/sql/migration.py",
>> line 52, in db_sync
>> return versioning_api.upgrade(CONF.sql.connection, repo_path, version)
>>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line
>> 186, in upgrade
>> return _migrate(url, repository, version, upgrade=True, err=err,
>> **opts)
>>   File "", line 2, in _migrate
>>   File
>> "/usr/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py",
>> line 159, in with_engine
>> return f(*a, **kw)
>>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/api.py", line
>> 366, in _migrate
>> schema.runchange(ver, change, changeset.step)
>>   File "/usr/lib/python2.7/dist-packages/migrate/versioning/schema.py",
>> line 91, in runchange
>> change.run(self.engine, step)
>>   File
>> "/usr/lib/python2.7/dist-packages/migrate/versioning/script/py.py", line
>> 145, in run
>> script_func(engine)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1.g3-py2.7.egg/keystone/common/sql/migrate_repo/versions/017_membership_role.py",
>> line 42, in upgrade
>> 'enabled': 'True'}))
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/engine/base.py",
>> line 1449, in execute
>> params)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/engine/base.py",
>> line 1584, in _execute_clauseelement
>> compiled_sql, distilled_params
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/engine/base.py",
>> line 1698, in _execute_context
>> context)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.9-py2.7-linux-x86_64.egg/sqlalchemy/engine/base.py",
>> line 1691, in _execute_context
>> context)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/SQLAlchemy-0.7.

Re: [Openstack] [Keystone] my token generated by curling http://localhost:35357/v2.0/tokens is too long...

[Dolph Mathews]

+1

However, I'm curious as to what makes it "too" long, or what's not working.
Can you provide an example?

-Dolph


On Sat, Feb 23, 2013 at 12:33 PM, Anne Gentle  wrote:

> I believe this is due to a change in default for grizzly-- token_format
> defaults to PKI instead of UUID in the [signing] section of the
> keystone.conf configuration file.
>
>
> http://docs.openstack.org/trunk/openstack-compute/admin/content/certificates-for-pki.html
>
> Anne
>
>
> On Sat, Feb 23, 2013 at 12:27 PM, Kun Huang wrote:
>
>> Hi, all
>> My token generated by curling http://localhost:35357/v2.0/tokens is too
>> long...
>>
>> Nearly 4000 chars in this token. I have change the max_token_size in
>> keystone.conf, but it doesn't work.
>>
>> For more, the token is not only long, and also not woring...
>>
>>
>> swift@storage-hk:~$ curl -s -d '{"auth": {"tenantName": "service",
>> "passwordCredentials": {"username": "swift", "password":"swiftpass"}}}' -H
>> 'Content-type: application/json' http://localhost:35357/v2.0/tokens |
>> python -mjson.tool
>> {
>> "access": {
>> "metadata": {
>> "is_admin": 0,
>> "roles": [
>> "9fe2ff9ee4384b1894a90878d3e92bab",
>> "acb42117c39945079ecf56bad7f441a1"
>> ]
>> },
>> "serviceCatalog": [
>> {
>> "endpoints": [
>> {
>> "adminURL": "
>> http://localhost:8774/v1.1/a20b1ea54bb54614956697b5484c9de1";,
>> "id": "eeaec0b2f9af4ecbae58225f05f58a13",
>> "internalURL": "
>> http://localhost:8774/v1.1/a20b1ea54bb54614956697b5484c9de1";,
>> "publicURL": "
>> http://localhost:8774/v1.1/a20b1ea54bb54614956697b5484c9de1";,
>> "region": "RegionOne"
>> }
>> ],
>> "endpoints_links": [],
>> "name": "nova",
>> "type": "compute"
>> },
>> {
>> "endpoints": [
>> {
>> "adminURL": "http://localhost:9292";,
>> "id": "7fc9afcca89f44e68875b88e05681dea",
>> "internalURL": "http://localhost:9292";,
>> "publicURL": "http://localhost:9292";,
>> "region": "RegionOne"
>> }
>> ],
>> "endpoints_links": [],
>> "name": "glance",
>> "type": "image"
>> },
>> {
>> "endpoints": [
>> {
>> "adminURL": "
>> http://localhost:8776/v1/a20b1ea54bb54614956697b5484c9de1";,
>> "id": "d826fa55273d4ed8bed3b744628629cf",
>> "internalURL": "
>> http://localhost:8776/v1/a20b1ea54bb54614956697b5484c9de1";,
>> "publicURL": "
>> http://localhost:8776/v1/a20b1ea54bb54614956697b5484c9de1";,
>> "region": "RegionOne"
>> }
>> ],
>> "endpoints_links": [],
>> "name": "volume",
>> "type": "volume"
>> },
>> {
>> "endpoints": [
>> {
>> "adminURL": "http://localhost:8773/services/Admin
>> ",
>> "id": "83dd85b5af21449ba5d5b9f530602f87",
>> "internalURL": "
>> http://localhost:8773/services/Cloud";,
>> "publicURL": "
>> http://localhost:8773/services/Cloud";,
>> "region": "RegionOne"
>> }
>> ],
>> "endpoints_links": [],
>> "name": "ec2",
>> "type": "ec2"
>> },
>> {
>> "endpoints": [
>> {
>> "adminURL": "http://localhost:/v1";,
>> "id": "674b345c9a9345978a74ed157f7f646d",
>> "internalURL": "
>> http://localhost:/v1/AUTH_a20b1ea54bb54614956697b5484c9de1";,
>> "publicURL": "
>> http://localhost:/v1/AUTH_a20b1ea54bb54614956697b5484c9de1";,
>> "region": "RegionOne"
>> }
>> ],
>> "endpoints_links": [],
>> "name": "swift",
>> "type": "object-store"
>> },
>> {
>> "endpoints": [
>> {
>> "adminURL": "http://localhost:35357/v2.0";,
>> "id": "c7384f41b3b1487b9dda90577f46dda6",
>> "internalURL": "http://localhost:5000/v2.0";,
>> "publicURL": "http://localhost:5000/v2.0";,
>> "region": "RegionOne"
>>   

Re: [Openstack] [Keystone]Question: Assignment of default role

[Dolph Mathews]

Yes, those are the two use cases we're supporting, although I'd encourage
Case 2, as it's generally much more intuitive.

-Dolph


On Mon, Feb 25, 2013 at 1:54 AM, Leo Toyoda <
toyoda-...@cnt.mxw.nes.nec.co.jp> wrote:

> Hi Adam
>
> Thanks a lot for your answer.
>
> It is my understanding follows. Would that be OK with you?
> Case1: Create a user *with* specifying the tenant.
> * Default role is assigned.
> * I need to assign the required roles in "keystone user-role-add".
> * The user has two roles.
>
> Case2: Create a user *without* specifying the tenant.
> * I need to assign the required roles and the tenant in "keystone
> user-role-add".
> * The user has one role.
>
> Thanks,
> Leo Toyoda
>
>
> > -Original Message-
> > From:
> > openstack-bounces+toyoda-reo=cnt.mxw.nes.nec.co.jp@lists.launc
> > hpad.net
> > [mailto:openstack-bounces+toyoda-reo=cnt.mxw.nes.nec.co.jp@lis
> > ts.launchpad.net] On Behalf Of Adam Young
> > Sent: Saturday, February 23, 2013 5:31 AM
> > To: openstack@lists.launchpad.net
> > Subject: Re: [Openstack] [Keystone]Question: Assignment of
> > default role
> >
> > Yes, this is new.  We are removing the direct associtation
> > between users and projects (Project members) and replacing it
> > with a Role (_member_)
> >
> > The _ is there to ensure it does not conflict with existing roles.
> >
> > The two different ways of associating users to projects was
> > causing problems.  With RBAC, we can now enforce policy about
> > project membership that we could not do before.
> >
> >
> >
> >
> >
> > On 02/21/2013 09:39 PM, Leo Toyoda wrote:
> > > Hi, everyone
> > >
> > > I'm using the master branch devstack.
> > > I hava a question about assignment of default role (Keystone).
> > >
> > > When I create a user to specify the tenant, '_member_' is
> > assigned to the roles.
> > > $ keystone user-create --name test --tenant-id e61..7f6 --pass test
> > > --email t...@example.com
> > > +--+---+
> > > | Property |  Value|
> > > +--+---+
> > > |  email   | te...@example.com |
> > > | enabled  |   True|
> > > |id| af1..8d2  |
> > > |   name   |   test|
> > > | tenantId | e61..7f6  |
> > > +--+---+
> > > $ keystone user-role-list --user test --tenant e61..7f6
> > > +--+--+--+---+
> > > |id|   name   | user_id  | tenant_id |
> > > +--+--+--+---+
> > > | 9fe..bab | _member_ | af1..8d2 | e61..7f6  |
> > > +--+--+--+---+
> > >
> > > Then, assign the "Member" role to the user.
> > > Hitting assigned two roles of 'Member' and '_member_'.
> > > $ keystone user-role-add --user af1..8d2 --role 57d..d1f --tenant
> > > e61..7f6 $ keystone user-role-list --user af1..8d2 --tenant e61..7f6
> > > +--+--+--+---+
> > > |id|   name   | user_id  | tenant_id |
> > > +--+--+--+---+
> > > | 57d..d1f |  Member  | af1..8d2 | e61..7f6  | 9fe..bab |
> > _member_  |
> > > | af1..8d2 | e61..7f6  |
> > > +--+--+--+---+
> > >
> > > When I create a user without specifying a tenant, I assign
> > 'Member' role.
> > > In this case, Only one role is assigned.
> > > $ keystone user-create --name test2 --pass test --email
> > > te...@example.com
> > > +--+---+
> > > | Property |  Value|
> > > +--+---+
> > > |  email   | te...@example.com |
> > > | enabled  |  True |
> > > |id|c22..a6d   |
> > > |   name   |  test2|
> > > | tenantId |   |
> > > +--+---+
> > > $ keystone user-role-add --user c22..a6d --role 57d..d1f  --tenant
> > > e61..7f6 $ keystone user-role-list --user c22..a6d --tenant e61..7f6
> > > +--+--+--+---+
> > > |id|   name   | user_id  | tenant_id |
> > > +--+--+--+---+
> > > | 57d..d1f |  Member  | c22..a6d | e61..7f6  |
> > > +--+--+--+---+
> > >
> > > Is it expected behavior that two rolls are assigned?
> > >
> > > Thanks
> > > Leo Toyoda
> > >
> > >
> > > ___
> > > 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

Re: [Openstack] Usage of New Keystone Domains with OpenStack

[Dolph Mathews]

As of Grizzly, the introduction of domains into OpenStack won't have any
impact on the rest of the deployment (AFAIK). Rather, the impact
is currently isolated to keystone and their use is effectively optional
(out of the box, keystone creates a single domain for you to work with --
the 'default' domain). There are a few projects that have expressed
interest in consuming domain data, but I'm not aware of anything landing in
time for Grizzly.


-Dolph


On Mon, Feb 25, 2013 at 11:14 AM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

> Hello,
>
> We are moving from OpenStack Essex to Grizzly and I am trying to find out
> how the new "domain" security collection will be used by the OpenStack
> services like Nova or Glance. I would greatly appreciate any information or
> documentation pointers.
>
> Regards,
>
> Mark Miller
>
> ___
> 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

Re: [Openstack] [Keystone][Swift] Problems with admin_user, admin_password, admin_tenant_name

[Dolph Mathews]

Setting the admin_token config is overriding the admin_user,
admin_password, and admin_tenant_name values by specifying a static token.
I'd recommend removing it and using the auth credentials you've already
provided.

-Dolph


On Thu, Feb 21, 2013 at 3:10 AM, Kun Huang  wrote:

> Following another question:
> In document:
> http://docs.openstack.org/developer/keystone/middleware_architecture.html
> ,
>
> [filter:tokenauth]
> paste.filter_factory = keystone.middleware.auth_token:filter_factory
> auth_host = 127.0.0.1
> auth_port = 35357
> auth_protocol = http
> auth_uri = http://127.0.0.1:5000/
> admin_token = Super999Sekret888Password777
> admin_user = admin
> admin_password = SuperSekretPassword
> admin_tenant_name = service
> ;Uncomment next line and check ip:port to use memcached to cache tokens
> ;memcache_servers = 127.0.0.1:11211
>
> That admin token is not admin_token = ADMIN in keystone, right?
>
>
>
>
>
> On Thu, Feb 21, 2013 at 4:06 PM, Kun Huang wrote:
>
>> I'm building environment with Swift + Keystone.
>> I have set admin_user, admin_password, admin_tenant_name, but it doesn't
>> work.
>> I followed the document:
>> http://docs.openstack.org/developer/swift/overview_auth.html and chmouel's
>> blog:
>> http://blog.chmouel.com/2011/11/24/swift-and-keystone-middleware-part1/
>>
>> My swift and keystone run well:
>>
>> [image: Inline image 1]
>>
>> But failed in curl:
>> [image: Inline image 2]
>>
>> I guess the value of admin_user/admin_password/admin_tenant_name doesn't
>> save in db.
>>
>> Which step do I missed? or some problems in my proxy config?
>>
>> Here is my current config.
>> [DEFAULT]
>> bind_port = 
>> user = swift
>>
>> [pipeline:main]
>> pipeline = catch_errors healthcheck cache authtoken keystoneauth
>> proxy-server
>>
>> [app:proxy-server]
>> use = egg:swift#proxy
>> account_autocreate = true
>>
>> [filter:keystoneauth]
>> use = egg:swift#keystoneauth
>> operator_roles = admin, swiftoperator
>>
>> [filter:authtoken]
>> # Delaying the auth decision is required to support token-less
>> # usage for anonymous referrers ('.r:*').
>> paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
>> auth_host = keystonehost
>> auth_port = 35357
>> auth_protocol = http
>> auth_uri = http://keystonehost:5000/
>> admin_tenant_name = service
>> admin_user = swift
>> admin_password = password
>>
>> [filter:cache]
>> use = egg:swift#memcache
>> set log_name = cache
>>
>> [filter:catch_errors]
>> use = egg:swift#catch_errors
>>
>> [filter:healthcheck]
>> use = egg:swift#healthcheck
>>
>
>
> ___
> 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

Re: [Openstack] keystone middleware

[Dolph Mathews]

On Mon, Feb 18, 2013 at 9:59 AM, pat  wrote:

> Hello,
>
> Sorry to disturb, but I have some questions regarding keystone middleware.
>
> Some introduction to problem: I need to integrate OpenStack to our existing
> infrastructure where all systems are integrated on REST and Web level using
> SSO-like system (there's generated a token string with specific
> information).
> Required behavior is to allow users log-in once in existing infrastructure
> and
> without additional log-in access OpenStack components.
>

I assume this is something completely proprietary then?


>
> I assume this is possible by implementing custom keystone drivers for
> identity
> and token. Is that correct?
> Should I also implement new policy and/or catalog driver?
>

If you're looking at folsom, you should only need to implement identity,
nothing more. You could even extend one of the existing drives (e.g. SQL)
and only implement certain methods.

In grizzly, we're also introducing pluggable authentication drivers that do
nothing more than authenticate users, which is probably more in line with
what you're looking for. Your driver could simply authenticate with your
existing system, and then create/update a user in keystone's SQL backend,
for example. We're providing password authentication out of the box at the
API level [1], but you could even implement your own authentication at the
API level (you'll need corresponding client-side support as well).

[1]:
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#the-password-authentication-method


>
> If this is possible I expect the keystone token is the token generated by
> my
> middleware driver(s) and such token is used by all other OpenStack parts.
> Is
> that correct?
>

You actually won't need to write any middleware. Rather, keystone is
designed to abstract existing, external authentication systems from
OpenStack's internal approach to auth (tokens). By writing a driver in
keystone, you're just redefining that abstraction.


> Does this affect way how the OpenStack internally validates token? Now when
> validating token the admin token has to be passed to validation request
> too. I
> expect not.
>

Your expectations are correct.


>
> Is there possible to chain more keystone authentication drivers? E.g. first
> check my custom and if this one fails then check SQL one.
>

We don't have that today (even with pluggable authentication). This is
something I'd like to see implemented... I think it'd be trivial to extend
our keystone.conf definitions for authentication method drivers to simply
be a prioritized list that keystone could query in order, until a driver
authenticates successfully (e.g. keystone's built-in password driver first,
then your own driver).


>
> I've searched internet to find some example of keystone middleware, but I
> didn't succeed :-\ Is there an example or step by step documentation
> (something for an ... :-))? I've read "Middleware Architecture"
> documentation
> and my questions are based on this.
>

That's the best documentation I'm aware of for the middleware architecture,
other than reading the source code of keystoneclient.middleware.auth_token
itself.


>
> Thanks a lot for your help.
>
>  Pat
>
>
> 
> Freehosting PIPNI - http://www.pipni.cz/
>
>
> ___
> 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

Re: [Openstack] keystone question - Solved

[Dolph Mathews]

On Mon, Feb 11, 2013 at 6:25 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Hello Dolph,
>
> ** **
>
> I was able to get the openstackclient installed after combining
> information from several wiki pages and modifying the install commands to
> use the current paths. I have a few more clarification questions if you
> don’t mind:
>
> ** **
>
> - keystoneclient currently provides a python client library for both
> Identity API v2 and v3
>
> - keystoneclient currently provides a command line interface for Identity
> API v2 -- but will not do so for Identity API v3
>
> **· **So then I will not see the new v3 Keystone commands for
> groups or domains in the keystoneclient CLI?
>
No, we don't have any plans to expose Identity API v3 features in
keystoneclient.

> 
>
> - openstackclient is working towards providing a unified CLI for all
> openstack projects, by consuming their python client libraries
>
> **· **So then I will see the new v3 Keystone commands for groups
> and domains in the openstackclinet CLI? The reason I ask is because after
> installing the openstackclient I still do not see the new commands. I can
> get to them from curl or from a REST client, but not from the command line
> interface.
>
Yes. There are still several major changes in review, and the effort is
still ramping up, relatively speaking. The clients do not follow the same
release cycle as the services, so we're lagging on client-side support.

> 
>
> So, the answer depends on your use case. If you want to write python,
> consume keystoneclient directly. If you want to use the CLI, use
> openstackclient, which uses keystoneclient behind the scenes.
>
> **· **I think we want both. We use the CLI to setup a base
> Keystone server environment and we use the client from Horizon.
>
> ** **
>
> Regards,
>
> ** **
>
> Mark Miller
>
> ** **
>
> ** **
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* Monday, February 11, 2013 1:09 PM
>
> *To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis)
> *Subject:* Re: [Openstack] keystone question - Solved
>
>  ** **
>
> keystoneclient is not being deprecated. I'd also suggest raising your
> question to the list.
>
>
> 
>
> ** **
>
> -Dolph
>
> ** **
>
> On Mon, Feb 11, 2013 at 3:00 PM, Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)  wrote:
>
> Hello Dolph,
>
>  
>
> Thank you for the answer. So it looks like keystoneclient is getting
> deprecated. So I tried to install openstackclient on an Ubuntu box and am
> getting the following error. Do you have any suggestions?
>
>  
>
> Regards,
>
>  
>
> Mark
>
>  
>
> sudo python tools/install_venv.py
>
> venv already exists...
>
> Installing dependencies with pip (this can take a while)...
>
> Traceback (most recent call last):
>
>   File "tools/install_venv.py", line 67, in 
>
> main(sys.argv)
>
>   File "tools/install_venv.py", line 61, in main
>
> install.install_dependencies()
>
>   File
> "/home/build/keystone-grizzly-2/python-openstackclient-master/tools/install_venv_common.py",
> line 126, in install_dependencies
>
> self.pip_install('pip==1.1')
>
>   File
> "/home/build/keystone-grizzly-2/python-openstackclient-master/tools/install_venv_common.py",
> line 116, in pip_install
>
> redirect_output=False)
>
>   File
> "/home/build/keystone-grizzly-2/python-openstackclient-master/tools/install_venv_common.py",
> line 76, in run_command
>
> check_exit_code)[0]
>
>   File
> "/home/build/keystone-grizzly-2/python-openstackclient-master/tools/install_venv_common.py",
> line 68, in run_command_with_code
>
> proc = subprocess.Popen(cmd, cwd=self.root, stdout=stdout)
>
>   File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
>
> errread, errwrite)
>
>   File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child***
> *
>
> raise child_exception
>
> OSError: [Errno 13] Permission denied
>
> root@build-HP-Compaq-6005-Pro-SFF-PC
> :~/keystone-grizzly-2/python-openstackclient-master#
>
>  
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* Monday, February 11, 2013 12:09 PM
>
>
> *To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis)
>
> *Subject:* Re: [Openstack] keystone 

Re: [Openstack] keystone question - Solved

[Dolph Mathews]

As for the client-side implementation, keystoneclient supports v3 as a
python library, whereas the CLI is being exposed in a different project (by
consuming keystoneclient):
https://github.com/openstack/python-openstackclient


-Dolph


On Mon, Feb 11, 2013 at 11:08 AM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis)  wrote:

>  Guang provided the answer for me with a sample JSON create domain
> request:
>
> { "domain":{
>  "name": "myDomain"
>  }
> }
>
> What through me off were the examples in the identity-api-v3 document.
> None of the domain JSON examples include the highest level "domain"
> element. The same is true for most of the other examples in the document.
>
> Mark
>
>
>
> -Original Message-
> From: openstack-bounces+mark.m.miller=hp@lists.launchpad.net [
> mailto:openstack-bounces+mark.m.miller=hp@lists.launchpad.net]
> On Behalf Of Miller, Mark M (EB SW Cloud - R&D - Corvallis)
> Sent: Thursday, February 07, 2013 1:42 PM
> To: Adam Young; openstack@lists.launchpad.net
> Subject: Re: [Openstack] keystone question
>
> Hi all,
>
> I have spent several days installing Grizzly-2 Keystone with SSL and PKI
> and think I have been successful. I can see some of the new API resources
> such as "v3/domains", "v3/groups", and "v3/services", but I don't see these
> listed as commands in the keystoneclient. Are they simply not implemented
> yet or was I unsuccessful when I installed Grizzly-2? I also want to know
> if the above resource APIs are fully functional?
>
> Regards,
>
> Mark Miller
>
> ___
> 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

Re: [Openstack] keystone / horizon :

[Dolph Mathews]

On Mon, Feb 11, 2013 at 8:02 AM, Mballo Cherif wrote:

> Hi everybody !
>
> I need help for keystone user/password authentication with horizon.
>
> **1)  **When I try to authenticate with my credential
> (login/password) In horizon dashboard, I have this message *Unable to
> retrieve authorized projet *! please what is that mean?
>
> How can I fix this issue.
>

It's hard to say for sure, but my instinct is that you have keystone's
public endpoint (port 5000) specified on a config somewhere that's
expecting keystone's the administrative API instead (port 35357). Check
adminUrl entry of the `identity` endpoint in your keystone service catalog
and any corresponding horizon configuration.


> 
>
> ** **
>
> **2)  **How can I trace the horizon call when a user  try to
> authenticate with the dashbord?
>
> ** **
>
> ** **
>
> Thanks you for your Answers
>
> ** **
>
> ** **
>
> Sherif!
>
> ___
> 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

Re: [Openstack] keystone delegate Athentication

[Dolph Mathews]

Adam Young is working on introducing delegation in grizzly:
https://blueprints.launchpad.net/keystone/+spec/trusts

I'm sure he'd appreciate some help if you'd like to contribute!


-Dolph


On Wed, Feb 6, 2013 at 8:54 AM, Mballo Cherif wrote:

> Hi everybody !
>
> I am wondering if it’s possible to delegate keystone Authentication to an 
> Authentication
> against a  server (I have one Strong Authentication server) or an Identity
> Provider?
>
> If I make modification on keystoneclient code it may be possible?
>
> Any ideas? Please help me!
>
> ** **
>
> ** **
>
> Thanks !
>
> ** **
>
> Sherif!
>
> ___
> 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

Re: [Openstack] how to get version information

[Dolph Mathews]

If you hit keystone's root endpoint you should also get a list of versions
in the response -- today that only includes /v2.0/

  # curl http://127.0.0.1:5000/ 


-Dolph


On Mon, Jan 28, 2013 at 3:07 AM, Ajiva Fan  wrote:

> hello everyone,
> i'm wondering if there is any rest api for componnets' version info.
>
> i read the http://api.openstack.org/api-ref.html and find:
> 1) keystone truly have a rest api for version info:
> # curl http://127.0.0.1:5000/v2.0/
> {"version": {"status": "beta", "updated": "2011-11-19T00:00:00Z",...
> 2) nova says it has, but sadly it does not work for essex
> # curl -H "X-Auth-Token:token-for-admin-tenant" http://127.0.0.1:8774/v2
> Authentication required
> # curl -H "X-Auth-Token:token-for-admin-tenant"
> http://127.0.0.1:8774/v2.0/
> {"choices": [{"status": "CURRENT",
> so the document may point to folsom, and essex has little difference.
>
> there seems no rest api for glance and horizon, and no CLI for nova
> and horizon while CLI has glance --version and nova-manage version
>
> so my question is:
> 1) is there any rest api for query components' version info in essex
> and folsom (beside keystone)?
> 2) if not, will it be implemented in future?
>
> thanks for any help.
>
> ___
> 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

Re: [Openstack] Glance image upload Keystone error

[Dolph Mathews]

I've seen this question come up a couple times now; this error handling
here needs to be improved with a decent error message.

I opened a bug on the issue:
https://bugs.launchpad.net/keystone/+bug/1103569


-Dolph


On Wed, Jan 23, 2013 at 11:04 AM, Adam Young  wrote:

>  On 01/23/2013 06:34 AM, Trinath Somanchi wrote:
>
> Hi Stackers-
>
>  I have installed glance and Keystone and configured them.
>
>
> Not sure how you installed, but you need to make sure the PKI provisioning
> is done.  You can do it by hand with the keystone_manage command.  Make
> sure you run it as the user that Keystone is going to run as, as it creates
> the certificates and Keystone (ajnd only Keystone) needs to be able to
> access those.
>
>
>  But When I upload a test image with glance, I got this error in keystone
> logs
>
>  (sqlalchemy.engine.base.Engine): 2013-01-23 17:04:57,904 INFO
> ('106298a47e5a4d129c7b8571e188c51e', 1)
> (keystone.common.cms): 2013-01-23 17:04:57,990 ERROR Signing error: Error
> opening signer certificate /etc/keystone/ssl/certs/signing_cert.pem
> 140702974211744:error:02001002:system library:fopen:No such file or
> directory:bss_file.c:398:fopen('/etc/keystone/ssl/certs/signing_cert.pem','r')
> 140702974211744:error:20074002:BIO routines:FILE_CTRL:system
> lib:bss_file.c:400:
> unable to load certificate
>
>  (root): 2013-01-23 17:04:57,991 ERROR Command 'openssl' returned
> non-zero exit status 3
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/common/wsgi.py",
> line 215, in __call__
> result = method(context, **params)
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/token/controllers.py",
> line 118, in authenticate
> config.CONF.signing.keyfile)
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/common/cms.py",
> line 140, in cms_sign_token
> output = cms_sign_text(text, signing_cert_file_name,
> signing_key_file_name)
>   File
> "/usr/local/lib/python2.7/dist-packages/keystone-2013.1-py2.7.egg/keystone/common/cms.py",
> line 135, in cms_sign_text
> raise subprocess.CalledProcessError(retcode, "openssl")
> CalledProcessError: Command 'openssl' returned non-zero exit status 3
>
>  Kindly help me resolve the issue
>
>  --
> Regards,
> --
> Trinath Somanchi,
> +91 9866 235 130
>
>
> ___
> 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

Re: [Openstack] [heat] Grizzly-2 development milestone available for Heat

[Dolph Mathews]

Grab a copy of the sample configuration file:

  https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample

On Tuesday, January 15, 2013, Mballo Cherif wrote:

> Hi everybody, I need help!
>
> I was trying to install Openstack Keystone standalone on a Ubuntu 12.04
> machine using the source tarball from Github
> http://docs.openstack.org/developer/keystone/installing.html . keystone
> was apparently installed correctly, however no keystone.conf file was
> created in either /etc or /etc/keystone folders. Thus, running anything
> further was not possible.
>
> ** **
>
> Can anyone help/direct me about what should be done?
>
> ** **
>
> Thanks you!
>
> ** **
>
> Sherif
>
> ** **
>
> ** **
>
> *From:* 
> openstack-bounces+cherif.mballo=gemalto@lists.launchpad.net  'cvml', 'gemalto@lists.launchpad.net');>[mailto:
> openstack-bounces+cherif.mballo  'openstack-bounces%2Bcherif.mballo');>=gemalto@lists.launchpad.net  'cvml', 'gemalto@lists.launchpad.net');>]
> *On Behalf Of *Martinx - ?
> *Sent:* mardi 15 janvier 2013 13:18
> *To:* Steven Hardy
> *Cc:* openstack@lists.launchpad.net  'openstack@lists.launchpad.net');>
> *Subject:* Re: [Openstack] [heat] Grizzly-2 development milestone
> available for Heat
>
> ** **
>
> Hi!
>
> ** **
>
> I just install Keystone and Glance on my Raring Ringtail "controller
> node"...
>
> ** **
>
> Should I install Heat now? Or is it better to install it between?
>
> ** **
>
> BTW, I'm using this guide to help me:
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/blob/stable/GRE/OpenStack_Folsom_Install_Guide_WebVersion.rst-
>  since it works great for Ubuntu 12.10...
> 
>
> ** **
>
> Thanks for the info!
>
> ** **
>
> Best,
>
> Thiago
>
> On 15 January 2013 07:28, Steven Hardy  'cvml', 'sha...@redhat.com');>>
> wrote:
>
> On Mon, Jan 14, 2013 at 01:20:09PM -0200, Martinx - ジェームズ wrote:
> > Hi!
> >
> >  Is Grizzly-2 available on Ubuntu Raring Ringtail (13.04) daily builds?
> >
> > Tks!
> > Thiago
>
> Since your question is in response to the Heat Grizzly-2 announcement, I
> should point out that Heat is not packaged for Ubuntu (yet!), so you will
> have to download the tarball and install from source to evaluate this
> release.
>
> Tarball:
> https://launchpad.net/heat/grizzly/grizzly-2
>
> Install procedure should be the similar to:
> http://wiki.openstack.org/Heat/GettingStartedUsingMasterOnUbuntu
>
> Assuming you already have a functional openstack installation, you can
> start
> at "Install Heat from master" and skip the git clone (just untar the
> tarball
> instead)
>
> This should be an interim solution as packaging for Ubuntu is in-progress:
> https://bugs.launchpad.net/heat/+bug/1083501
>
> Steve
>
> ** **
>


-- 

-Dolph
___
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] [OpenStack][Swift] Fast way of uploading 200GB of 200KB files to Swift

[Dolph Mathews]

If memcache is being utilized by your keystone middleware, you should see
keystone attaching to it on the first incoming request, e.g.:

  keystoneclient.middleware.auth_token [INFO]: Using Keystone memcache for
caching token

You may also want to use auth_token from keystoneclient >= v0.2.0 if you're
not already (instead of from keystone itself).


-Dolph


On Mon, Jan 14, 2013 at 11:43 AM, Leander Bessa Beernaert <
leande...@gmail.com> wrote:

> Are you by any chance referring to this topic
> https://lists.launchpad.net/openstack/msg08639.html regarding the
> keystone token cache? If so I've already added the configuration line and
> have not noticed any speedup :/
>
>
>
>
> On Mon, Jan 14, 2013 at 5:19 PM, Leander Bessa Beernaert <
> leande...@gmail.com> wrote:
>
>> I'm using the ubuntu 12.04 packages of the folsom repository by the way.
>>
>>
>> On Mon, Jan 14, 2013 at 5:18 PM, Chuck Thier  wrote:
>>
>>> On Mon, Jan 14, 2013 at 11:03 AM, Leander Bessa Beernaert
>>>  wrote:
>>> > Also, I'm unable to run the swift-bench with keystone.
>>> >
>>>
>>> Hrm... That was supposed to be fixed with this bug:
>>> https://bugs.launchpad.net/swift/+bug/1011727
>>>
>>> My keystone dev instance isn't working at the moment, but I'll see if
>>> I can get one of the team to take a look at it.
>>>
>>> --
>>> Chuck
>>>
>>
>>
>
> ___
> 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

Re: [Openstack] Error in Horizon or misconfiguration?

[Dolph Mathews]

Are you still seeing EndpointNotFound's on the latest version of
keystoneclient? Even without a fix, it was simply a condition that didn't
need to be logged (especially as an error).


-Dolph


On Thu, Jan 10, 2013 at 8:07 PM, Sina Sadeghi  wrote:

>  Guys this is a bug I have been trying to get resolved for _ages_ now and
> it seems nobody cares about it:
>
> https://bugs.launchpad.net/python-keystoneclient/+bug/1036342
>
>
>
> --
> *Sina Sadeghi*
> Lead Cloud Engineer
>
> *Aptira Pty Ltd*
> 1800 APTIRA
> aptira.com 
> Follow @aptira 
>
>  On 11/01/13 01:33, Ray Sun wrote:
>
> Maybe this bugs is related with your Quota Summary.
>
>  https://bugs.launchpad.net/horizon/+bug/1055929
>
>  Just replace 'usage.quota' with 'usage.quotas' in
> horizon/templates/horizon/common/_quota_summary.html.
>
>  - Ray
> Yours faithfully, Kind regards.
>
> CIeNET Technologies (Beijing) Co., Ltd
> Email: qsun01...@cienet.com.cn
> Office Phone: +86-01081470088-7079
> Mobile Phone: +86-13581988291
>
>
> On Thu, Jan 10, 2013 at 9:09 PM, JuanFra Rodriguez Cardoso <
> juanfra.rodriguez.card...@gmail.com> wrote:
>
>> Thanks for replying quickly!
>>
>> Yes, I knew about this property. By default is 'internalURL', but
>> although it's modified and restarted httpd, errors related to
>> EndpointNotFound continue logging with endpoint_type='adminURL'.
>>
>> On the other hand, in Horizon, the Quota Summary in Project tab, is shown
>> empty. Any idea about that?
>>
>> Thanks a lot!
>> JuanFra
>>
>>
>> 2013/1/10 Diego Parrilla Santamaría 
>>
>>> You can change the endpoint type in Horizon:
>>>
>>>  Modify this file:
>>> /etc/openstack-dashboard/local_settings.py
>>>
>>>  and add (or edit) this property:
>>> OPENSTACK_ENDPOINT_TYPE=endpoint_type
>>>
>>>  and endpoint_type can be internalURL, publicURL and adminURL, as usual.
>>>
>>>  Cheers
>>> Diego
>>>
>>>   --
>>>  Diego Parrilla
>>>  *CEO*
>>> *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 
>>> 29<%2B34%20649%2094%2043%2029>|
>>> skype:diegoparrilla*
>>> * 
>>>  *
>>>
>>> *
>>>
>>>
>>>
>>>  On Thu, Jan 10, 2013 at 1:33 PM, JuanFra Rodriguez Cardoso <
>>> juanfra.rodriguez.card...@gmail.com> wrote:
>>>
  Hi guys!

 Do you know if this Horizon's bug have been solved? In my fresh
 installation (2012.2.1 from EPEL), it keeps crashing.
 However, remaining operations in dashboard work fine!

   [Thu Jan 10 13:20:19 2013] [error] Traceback (most recent call last):
 [Thu Jan 10 13:20:19 2013] [error]   File
 "/usr/lib/python2.6/site-packages/keystoneclient/v2_0/client.py", line 135,
 in _extract_service_catalog
 [Thu Jan 10 13:20:19 2013] [error] endpoint_type='adminURL')
 [Thu Jan 10 13:20:19 2013] [error]   File
 "/usr/lib/python2.6/site-packages/keystoneclient/service_catalog.py", line
 73, in url_for
 [Thu Jan 10 13:20:19 2013] [error] raise
 exceptions.EndpointNotFound('Endpoint not found.')
 [Thu Jan 10 13:20:19 2013] [error] EndpointNotFound: Endpoint not found.
 [Thu Jan 10 13:20:21 2013] [error] unable to retrieve service catalog
 with token


 It could be a great chance for my first contribution to Horizon code?
 could I assign myself this bug?

 Thanks,
  JuanFra.

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

Re: [Openstack] Error in Horizon or misconfiguration?

[Dolph Mathews]

The fix was made to keystoneclient, so it does not require backporting. You
can use the latest keystoneclient with either diablo, Essex or Folsom.

-Dolph

On Thursday, January 10, 2013, Matthias Runge wrote:

> On 01/10/2013 01:33 PM, JuanFra Rodriguez Cardoso wrote:
> > Hi guys!
> >
> > Do you know if this Horizon's bug have been solved? In my fresh
> > installation (2012.2.1 from EPEL), it keeps crashing.
> > However, remaining operations in dashboard work fine!
> >
> Its' a known error in keystone, which has been fixed IMHO. I'm currently
> not sure, if the fix has been backported to Folsom.
>
> Matthias
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net 
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>


-- 

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

[Openstack] [keystone] IBM DB2 configuration

[Dolph Mathews]

(raising to the mailing list)

Which DB2 driver are you using? I was referring to:
http://code.google.com/p/ibm-db/wiki/README

... which shows an example connection string for sqlalchemy as:

>>> db2 = sqlalchemy.create_engine('ibm_db_sa://
db2inst1:sec...@host.name.com:5/pydev')

-Dolph


On Thu, Dec 20, 2012 at 4:05 AM, Kevin-Yang wrote:

> Dolph,
>
> Really appreciated for your response.
>
> My VM configuration is:
>
> OS ->
> Red Hat Enterprise Linux Server release 6.3 (Santiago)
>
> DB2 ->
> Informational tokens are "DB2 v9.7.0.0", "s090521", "LINUXAMD6497", and Fix
> Pack "0"
> ibm_db ->
> http://pypi.python.org/packages/source/i/ibm_db/ibm_db-2.0.0.tar.gz#md5=709c576c0ec2379ca15049f5c861beb1
> ibm_db_sa ->
>
> When i changed from "ibmdb" -> "ibm_db_sa", I came with a different error
> -> Could not determine dialect for 'ibm_db_sa'.
>
> ##
> Traceback (most recent call last):
>   File "/usr/local/bin/keystone-manage", line 5, in 
> pkg_resources.run_script('keystone==2012.2', 'keystone-manage')
>   File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 499, in
> run_script
>   File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 1239, in
> run_script
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/EGG-INFO/scripts/keystone-manage",
> line 28, in 
> cli.main(argv=sys.argv, config_files=config_files)
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py",
> line 164, in main
> return run(cmd, (args[:1] + args[2:]))
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py",
> line 147, in run
> return CMDS[cmd](argv=args).run()
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py",
> line 35, in run
> return self.main()
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/cli.py",
> line 56, in main
> driver.db_sync()
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/identity/backends/sql.py",
> line 136, in db_sync
> migration.db_sync()
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/common/sql/migration.py",
> line 49, in db_sync
> current_version = db_version()
>   File
> "/usr/local/lib/python2.7/site-packages/keystone-2012.2-py2.7.egg/keystone/common/sql/migration.py",
> line 61, in db_version
> return versioning_api.db_version(CONF.sql.connection, repo_path)
>   File "", line 2, in db_version
>   File
> "/usr/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py",
> line 155, in with_engine
> engine = construct_engine(url, **kw)
>   File
> "/usr/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py",
> line 140, in construct_engine
> return create_engine(engine, **kwargs)
>   File "build/bdist.linux-x86_64/egg/sqlalchemy/engine/__init__.py", line
> 338, in create_engine
>   File "build/bdist.linux-x86_64/egg/sqlalchemy/engine/strategies.py",
> line 50, in create
>   File "build/bdist.linux-x86_64/egg/sqlalchemy/engine/url.py", line 123,
> in get_dialect
>
> sqlalchemy.exc.ArgumentError: Could not determine dialect for 'ibm_db_sa'.
>
> ##
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/987121
>
> Title:
>   strict constraint for database table creation
>
> Status in OpenStack Identity (Keystone):
>   Fix Released
>
> Bug description:
>   OpenStack claims that any type of database supporting SQLAlchemy can be
> taken as the database for OpenStack use.
>   In some databases, if a column is defined as UNIQUE, it must be
> specified NOT NULL at the same time, e.g. IBM DB2, which is SQLAlchemy
> supporting. I am doing some tests with DB2 now.
>   For the tables TENANT, USER and ROLE, they all have the column NAME, but
> they don't define this column NOT NULL. For database like MYSQL, it is
> permitted and keystone-manage db_sync works well. However, for database
> with strict constrains, like IBM DB2, this is not allowed. Running
> keystone-manage db_sync will prompt the error, which tells me UNIQUE and
> NOT NULL must be specified for the column NAME.
>   Suggestion:
>   In the code keystone/identity/backends/sql.py, we have
>   name = sql.Column(sql.String(64), unique=True)
>
>   If we change it into
>   name = sql.Column(sql.String(64), unique=True, nullable=False),
>   this issue will be solved.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/987121/+subscriptions
>
___
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] Can somebody offer some help regarding Keystone interaction with LDAP in Essex?

[Dolph Mathews]

Make sure you're specifying a tenant (e.g. OS_TENANT_NAME) in order to
receive authorization (e.g. the admin role) to perform nova list. You can
debug the authn/authz process using "keystone token-get" (this doc is for
folsom, but should work for essex, although the arguments may have changed,
check "keystone --help"):

http://docs.openstack.org/trunk/openstack-compute/install/apt/content/verifying-identity-install.html

If you're running into issues between your LDAP schema and what keystone
Essex expects, it's worth pointing out that keystone became a lot more
flexible in terms of LDAP configuration in Folsom.


-Dolph



On Tue, Dec 18, 2012 at 3:07 PM, Christopher Smith wrote:

> Hey everybody,
>
> We're trying very hard to build an Openstack cluster here, and I've been
> running into some trouble with the Keystone LDAP identity backend.  I have
> every expectation that this is just something I have misconfigured, but
> honestly the documentation seems somewhat lacking for this, so I haven't
> been able to figure out what is going wrong.
>
> Here's the current situation:
>
> We have gotten an entire Openstack installation working, using the SQL
> backends to keystone.  We're currently trying to move the identity into
> LDAP.  This has caused a few problems, but the one I'm stuck on at the
> moment is that the admin user seems not to be associated with the admin
> role.  Nor does keystone seem to be attempting at all to look up role
> information.
>
> The relevant section of keystone.conf looks like:
>
> [ldap]
> url = ldap://ldap.wolfram.com
> tree_dn = ou=OpenStack,dc=wolfram,dc=com
> user_tree_dn = ou=Users,ou=OpenStack,dc=wolfram,dc=com
> role_tree_dn = ou=Roles,ou=OpenStack,dc=example,dc=com
> tenant_tree_dn = ou=Groups,ou=OpenStack,dc=wolfram,dc=com
> user = cn=directory,ou=misc,ou=OpenStack,dc=wolfram,dc=com
> password = redacted (but the bind is successful)
> suffix = cn=wolfram,cn=com
>
> Now, I've captured the traffic between keystone and ldap for when I
> execute any nova operation, say, nova list.  What I get is a set of
> successful binds as cn=directory, a search request against ou=Users, one
> against ou=Groups, one for admin's UID in ou=Users, then re-bind as the
> Admin object -- also successful, so I assume I'm authenticated. Next I have
> a search by ID for the admin group.  This, depending on the operation,
> might be repeated along with additional lookups for the lists of users and
> groups against the corresponding OUs.  Anyway, all of this looks reasonable
> to me, expect that it doesn't appear to ever be trying to assign roles,
> which I'd like for it to do.
>
> My LDAP structure looks like this:
>
> ou=OpenStack
>   ou=Groups
> Contains a set of groupOfNames objects with cn=id,ou=name member=DN of
> member.  Our tenants are stored here.
>   ou=misc
> This is just a place to stick the keystone directory user for the
> initial bind.
>   ou=Roles
> Contains a set of organizationalRole objects with ou=name, cn=id,
> roleOccupant=DN of member
>   ou=Users
> Contains a set of inetOrgPerson objects with ou=username and cn=id
>
> Any ideas what I'm missing?
>
> Chris
>
> --
> Christopher Smith
> Systems Engineer, Wolfram Research
>
> ___
> 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

Re: [Openstack] Create tenant with RESTful api

[Dolph Mathews]

I'd first suggesting looking for an existing PHP binding (I'm not aware of
one).

You can also simply try "keystone tenant-create" and emulate it's request
if that's all you need. I's implementation is here:


https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v2_0/tenants.py

Alternatively, that portion of the API is defined here:


https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/docbkx/extensions/OS-KSADM/OS-KSADM-admin.wadl#L135

You could also just make system calls from PHP, e.g. system("keystone
tenant-create ...") or use popen()


-Dolph



On Fri, Dec 14, 2012 at 1:05 PM, Guillermo Alvarado <
guillermoalvarad...@gmail.com> wrote:

> Because I am using PHP, so I am making the requests with REST.
>
>
> 2012/12/14 Matt Joyce 
>
>> Is there a reason you are not using the keystone client api?
>>
>> On Fri, Dec 14, 2012 at 10:58 AM, Guillermo Alvarado <
>> guillermoalvarad...@gmail.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> Please, someone can give me information about how to create a tenant
>>> with a REST request. I am trying to develop a module to use my legacy
>>> billing software, so I need to create tenants, create a vm, terminate it
>>> and suspend it. I can achieve the later with the vm but I can not find how
>>> to make the request to create a tenant...
>>>
>>> Thanks in advance,
>>> Best regards.
>>>
>>> ___
>>> 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

Re: [Openstack] [SWIFT] Upgrade from 1.4.8 to 1.7.4 question

[Dolph Mathews]

+1; if it doesn't work, it's a bug.


-Dolph



On Tue, Dec 11, 2012 at 4:32 PM, Matt Joyce wrote:

> My guess would be that it would work.  The keystone API hasn't changed
> massively between essex and folsom.
>
> I have not tested.
>
> But I am fairly confident it would work just fine.
>
> -Matt
>
> On Tue, Dec 11, 2012 at 2:25 PM, Alejandro Comisario <
> alejandro.comisa...@mercadolibre.com> wrote:
>
>> Hi guys, we are planning to upgrade our production cluster from 1.4.8 to
>> 1.7.4 to have the several features of the new version.
>> One of the main doubts before dive into this task is as follow :
>>
>> Is it possible to use SWIFT 1.7.4 with Keystone/ESSEX ? Or is MUST to
>> have Keystone from Folsom release ?
>>
>> Thanks in advance !
>>
>> *
>> *
>> *Alejandrito*
>>
>> ___
>> 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

Re: [Openstack] Problem with keystone on Debian

[Dolph Mathews]

The arguments for the commands you need vary a bit by release, but for
interactive help, use:

$ keystone help role-create
$ keystone help tenant-create
$ keystone help user-create
$ keystone help user-role-add

In the latest release of keystoneclient, also try:

$ keystone help bootstrap

... which shortcuts the process of using the above 4 commands.


-Dolph



On Thu, Dec 6, 2012 at 12:21 PM, Guilherme Russi  wrote:

> Hello Guys,
>
>  I'm trying to install OpenStack on Debian Wheezy, but i'm getting some
> problems with keystone, when i try to create a user in a tenant using
> the --tenant-id command, it returns the error: keystone: error:
> unrecognized arguments: --service-id .
>
>  Does anybody knows if it is a version problem, I've tried on ubuntu 12.10
> and it worked.
>
> Hope someone can help me.
>
> Thank you.
>
>
> ___
> 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

Re: [Openstack] [Keystone] LDAP Backend for Catalog

[Dolph Mathews]

Neither have I.


-Dolph


On Mon, Dec 3, 2012 at 1:25 PM, heckj  wrote:

> I haven't heard any demand for it -
>
> - joe
>
> On Dec 3, 2012, at 11:13 AM, Adam Young  wrote:
> > Right now, only the Identity submodule has an LDAP backend.  This is
> user, tenants, and roles.  Is there any requirement for the Catalog to have
> an LDAP back end?  Endpoints and Services do not necessarily map directly
> to the LDAP view of machines, but could probably be made to fit.  I will
> start investigating the feasibility if there is any demand for it.
> >
> > ___
> > 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

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

[Dolph Mathews]

I'm just pointing out that the same data used for validating belongsTo on
the server-side is included in the response body (assuming a GET and not
HEAD).


-Dolph


On Thu, Nov 15, 2012 at 2:51 PM, Jorge Williams <
jorge.willi...@rackspace.com> wrote:

>  (inline)
>
>  On Nov 15, 2012, at 2:06 PM, Dolph Mathews wrote:
>
> Without belongsTo, you can still validate the tenant scope client-side, so
> it's a bit redundant.
>
>
>  Not sure what you mean.  Can you be more specific?
>
> However, if you're making a HEAD call to validate the token, you obviously
> need the server to do that additional validation for you.
>
>
>  Right.
>
>
>  -Dolph
>
>
> On Thu, Nov 15, 2012 at 8:20 AM, Jorge Williams <
> jorge.willi...@rackspace.com> wrote:
>
>> No, it's optional.
>>
>> Token validation returns what it normally does.  The only thing belongs
>> to does is that you fail token validation if the given tenant is not
>> covered by the scope of the token.
>>
>> -jOrGe W.
>>
>> On Nov 14, 2012, at 11:18 PM, Yee, Guang wrote:
>>
>> > Is "belongsTo" mandatory? If not, what will token validation API return?
>> >
>> > {"access": [list of tokens]}
>> >
>> > ?
>> >
>> >
>> > Guang
>> >
>> >
>> > -Original Message-
>> > From: Jorge Williams [mailto:jorge.willi...@rackspace.com]
>> > Sent: Wednesday, November 14, 2012 2:47 PM
>> > To: OpenStack Development Mailing List
>> > Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
>> > Subject: Re: [openstack-dev] [Openstack] Fwd: [keystone] Tokens
>> representing
>> > authorization to projects/tenants in the Keystone V3 API
>> >
>> >> From an API perspective the changes required are the following:
>> >
>> >   1.  The validate call returns a list of tenants instead of a
>> single
>> > tenant.
>> >
>> > If the tenant id is in the URI of the API, then the validation
>> middleware
>> > can assert that the tenant id is in the list of IDs.
>> >
>> > Not sure if there's any additional changes, but I don't think so.
>> >
>> > An alternative approach is to use the belongsTo query parameter in the
>> > validate call.  So if you know the tenantId of the resource, you can
>> issue a
>> > validate with ?belongsTo="tenatId"  and validation if the tenant is not
>> in
>> > the list of tenatIds for the token.  The belongsTo query parameter is
>> in the
>> > validate token call in the API today
>> >
>> >
>> http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_val
>> >
>> idateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1
>> > 356.html
>> >
>> > And we use it quite a bit in our implementation, when we validate
>> tokens --
>> > that is in the case where a token may have access to multiple tenants.
>> >
>> > Thoughts?
>> >
>> > -jOrGe W.
>> >
>> >
>> > On Nov 14, 2012, at 3:53 PM, heckj wrote:
>> >
>> >> If we're going to assert it's supported, we're doing an incredible
>> > dis-service to writing a spec to not implement that aspect of the spec,
>> as
>> > that kind of set up just leads to incompatibilities and confusion when
>> > asserting how the spec should be used to provide interoperability.
>> >>
>> >> If we accept this as a spec addition, then we MUST have an
>> implementation
>> > that makes it clear how we expect to interoperate with that aspect of
>> the
>> > specification, even if it's a configuration option that we don't
>> normally
>> > enable. If we don't test and validate it to prove interoperability,
>> then the
>> > spec is a worthless digital "piece of paper".
>> >>
>> >> So under that pretext, I welcome suggestions on how to interpret the
>> spec
>> > you're proposing to some concrete implementations that can be verified
>> for
>> > interoperability, and that are compatible with the existing and/or
>> upcoming
>> > implementations for V3 API.
>> >>
>> >> -joe
>> >>
>> >> On Nov 14, 2012, at 1:35 PM, Joe Savak 
>> wrote:
>> >>> Hi Joe,
>> >>> If I'm working across multiple tenants, I'd prefer one token

Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API

[Dolph Mathews]

Without belongsTo, you can still validate the tenant scope client-side, so
it's a bit redundant. However, if you're making a HEAD call to validate the
token, you obviously need the server to do that additional validation for
you.


-Dolph


On Thu, Nov 15, 2012 at 8:20 AM, Jorge Williams <
jorge.willi...@rackspace.com> wrote:

> No, it's optional.
>
> Token validation returns what it normally does.  The only thing belongs to
> does is that you fail token validation if the given tenant is not covered
> by the scope of the token.
>
> -jOrGe W.
>
> On Nov 14, 2012, at 11:18 PM, Yee, Guang wrote:
>
> > Is "belongsTo" mandatory? If not, what will token validation API return?
> >
> > {"access": [list of tokens]}
> >
> > ?
> >
> >
> > Guang
> >
> >
> > -Original Message-
> > From: Jorge Williams [mailto:jorge.willi...@rackspace.com]
> > Sent: Wednesday, November 14, 2012 2:47 PM
> > To: OpenStack Development Mailing List
> > Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> > Subject: Re: [openstack-dev] [Openstack] Fwd: [keystone] Tokens
> representing
> > authorization to projects/tenants in the Keystone V3 API
> >
> >> From an API perspective the changes required are the following:
> >
> >   1.  The validate call returns a list of tenants instead of a single
> > tenant.
> >
> > If the tenant id is in the URI of the API, then the validation middleware
> > can assert that the tenant id is in the list of IDs.
> >
> > Not sure if there's any additional changes, but I don't think so.
> >
> > An alternative approach is to use the belongsTo query parameter in the
> > validate call.  So if you know the tenantId of the resource, you can
> issue a
> > validate with ?belongsTo="tenatId"  and validation if the tenant is not
> in
> > the list of tenatIds for the token.  The belongsTo query parameter is in
> the
> > validate token call in the API today
> >
> >
> http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_val
> >
> idateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1
> > 356.html
> >
> > And we use it quite a bit in our implementation, when we validate tokens
> --
> > that is in the case where a token may have access to multiple tenants.
> >
> > Thoughts?
> >
> > -jOrGe W.
> >
> >
> > On Nov 14, 2012, at 3:53 PM, heckj wrote:
> >
> >> If we're going to assert it's supported, we're doing an incredible
> > dis-service to writing a spec to not implement that aspect of the spec,
> as
> > that kind of set up just leads to incompatibilities and confusion when
> > asserting how the spec should be used to provide interoperability.
> >>
> >> If we accept this as a spec addition, then we MUST have an
> implementation
> > that makes it clear how we expect to interoperate with that aspect of the
> > specification, even if it's a configuration option that we don't normally
> > enable. If we don't test and validate it to prove interoperability, then
> the
> > spec is a worthless digital "piece of paper".
> >>
> >> So under that pretext, I welcome suggestions on how to interpret the
> spec
> > you're proposing to some concrete implementations that can be verified
> for
> > interoperability, and that are compatible with the existing and/or
> upcoming
> > implementations for V3 API.
> >>
> >> -joe
> >>
> >> On Nov 14, 2012, at 1:35 PM, Joe Savak  wrote:
> >>> Hi Joe,
> >>> If I'm working across multiple tenants, I'd prefer one token that I
> > can securely handle that proves access rights to the tenants I'm working
> > with. Handling multiple tokens increases the complexity of clients
> needing
> > to provide multi-tenancy access to an authenticated identity. It also
> adds
> > more calls to keystone.
> >>>
> >>> Again, I think that having the keystone reference implementation
> restrict
> > tokens to 1 tenant is fine. We shouldn't have such arbitrary
> restrictions in
> > the API contract though. It needs to be extensible and flexible to allow
> for
> > the all sorts of use cases that are likely to occur.
> >>>
> >>> Thanks,
> >>> joe
> >>>
> >>> -Original Message-
> >>> From: heckj [mailto:he...@mac.com]
> >>> Sent: Tuesday, November 13, 2012 3:59 PM
> >>> To: Joe Savak
> >>> Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
> > (openstack@lists.launchpad.net)
> >>> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens
> > representing authorization to projects/tenants in the Keystone V3 API
> >>>
> >>> Hey Joe:
> >>>
> >>> Currently a user scoped token doesn't include a service catalog -
> mostly
> > because I think the service catalog generally requires tenant_id's to
> > interpolate into the values to provide it. That doesn't mean we can't put
> > in/include service catalog endpoints where that value doesn't need to be
> > determined.
> >>>
> >>> I'm also questioning the value of providing a token scoped to all
> tenants
> > associated with a user - that seems to have the same value as just using
> a
> > user tok

Re: [Openstack] [Folsom] Horizon not working

[Dolph Mathews]

We just fixed a similar issue in keystoneclient -- what release is this
running against?

https://bugs.launchpad.net/python-keystoneclient/+bug/1074784

https://review.openstack.org/#/c/15410/


-Dolph


On Thu, Nov 8, 2012 at 5:46 AM, Robert van Leeuwen <
robert.vanleeu...@spilgames.com> wrote:

>  > [Fri Nov 02 14:25:28 2012] [error] unable to retrieve service catalog
> with
> > token
> > [Fri Nov 02 14:25:28 2012] [error] Traceback (most recent call last):
> > [Fri Nov 02 14:25:28 2012] [error] File
> > "/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py", line
> 132,
> > in _extract_service_catalog
> > [Fri Nov 02 14:25:28 2012] [error] endpoint_type='adminURL')
> > [Fri Nov 02 14:25:28 2012] [error] File
> > "/usr/lib/python2.7/dist-packages/keystoneclient/service_catalog.py",
> line
> > 62, in url_for
> > [Fri Nov 02 14:25:28 2012] [error] raise
> > exceptions.EndpointNotFound('Endpoint not found.')
> > [Fri Nov 02 14:25:28 2012] [error] EndpointNotFound: Endpoint not found.
>
> Sounds like keystone is not properly setup.
> Maybe one of the required endpoints is not setup?
> ( I think you will need at least 4 endpoints to make it work.
> They are for the following services: identity, image, compute, volume)
>
> For debugging you can take a look at the keystone log so you can see the
> contents of the created tokens.
>
> Regards,
> Robert van Leeuwen
>
>
>
>
>
> ___
> 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

Re: [Openstack] Id collision across multiple data center deployments

[Dolph Mathews]

The ID's generated by keystone are implemented using random UUID's for
exactly this use case.


-Dolph


On Sat, Nov 3, 2012 at 11:49 PM, Salman A Baset  wrote:

> Hello folks,
>
> Suppose there is a single BSS managing multiple data centers, each running
> independent OpenStack OSS.
>
> Is there any possibility of OpenStack keystone or other ids to be similar
> with another deployment? (in particular tenant_id, user_id etc). I don't
> think this is the case (assuming uuids) but want to confirm with folks.
>
> Thanks.
>
> Best Regards,
>
> Salman A. Baset
> Research Staff Member, IBM T. J. Watson Research Center
> Tel: +1-914-784-6248
>
>
>
> ___
> 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

Re: [Openstack] [OpenStack] Limiting new roles

[Dolph Mathews]

I'm specifically referring to keystone, because you mention "...this role
only  can create tentants and roles..." If you can create tenants and roles
in keystone, you also have the power to create new users and grant yourself
additional roles in keystone, due to the binary nature of the policy
implementation in keystone today (thereby -- and unfortunately -- defeating
the rest of your statement: "... but cannnot change quotas or modify
images").

-Dolph


On Wed, Oct 31, 2012 at 5:29 PM, Guillermo Alvarado <
guillermoalvarad...@gmail.com> wrote:

> I know the implementation is not binay, you can modify the permissions
> related with nova/glance/swifth of the differents roles. I doubt is if
> horizon know wich template can view each user...
>
>
> 2012/10/31 Dolph Mathews 
>
>> With regard to keystone, the current policy implementation is entirely
>> binary in that a role may either have total control over keystone or none.
>> The implementation in Grizzly is much more granular.
>>
>> -Dolph
>>
>>
>> On Wed, Oct 31, 2012 at 2:35 PM, Guillermo Alvarado <
>> guillermoalvarad...@gmail.com> wrote:
>>
>>> Hi everyboy,
>>>
>>> I want to create a new role, named "another-admin", so this role only
>>>  can create tentants and roles but cannnot change quotas or modify images
>>> and all other actions that admin role can do.
>>>
>>> I read about create rules in the policy.json of each service (nova,
>>> keystone, glance, swift) but my doubt is: How can I limit the
>>> views/templates/urls of Horizon, I mean, I want that the role
>>> "another-admin" can not see templates related to glance and can not see
>>> that menu.
>>>
>>> Thanks in advance,
>>> Best Regards.
>>>
>>>
>>>
>>> ___
>>> 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

Re: [Openstack] Verification of Keystone Installation fails

[Dolph Mathews]

There are basically two rules at work:

1) an existing token takes precedence over username+password credentials.
2) CLI options take precedence over configuration from the environment.

In Folsom, these options look like:

(existing token)
--os-token / OS_SERVICE_TOKEN
--os-endpoint / OS_SERVICE_ENDPOINT

(credentials)
--os-username / OS_USERNAME
--os-password / OS_PASSWORD
--os-tenant-name / OS_TENANT_NAME
--os-auth-url / OS_AUTH_URL

(there are also a few other options like region, api version, etc)

Rule 1 is universally applied before rule 2, which means the token +
endpoint from the environment is taking precedence over username + password
from the CLI. IMO, it's a bug that rule 2 isn't applied before rule 1.

-Dolph


On Wed, Oct 31, 2012 at 3:32 PM, Joshua Harlow wrote:

> I think the overall issue is connected to
> https://bugs.launchpad.net/keystone/+bug/962600
>
> Right? Seems like that is still happening :-(
>
> From: Ahmed Al-Mehdi 
> Date: Wednesday, October 31, 2012 1:15 PM
> To: Dolph Mathews 
> Cc: Joseph Heck , "openstack@lists.launchpad.net" <
> openstack@lists.launchpad.net>
>
> Subject: Re: [Openstack] Verification of Keystone Installation fails
>
> Hi Dolph,
>
> Awesome, that worked.  Thank you very much.  Just out of curiosity, what
> was the exact conflict?   Between which environment variable and option
> passed to the CLI?
>
> Regards,
> Ahmed.
>
>
> From: Dolph Mathews 
> Date: Wednesday, October 31, 2012 10:46 AM
> To: Ahmed Al-Mehdi 
> Cc: "openstack@lists.launchpad.net" ,
> Joseph Heck 
> Subject: Re: [Openstack] Verification of Keystone Installation fails
>
> I was able to reproduce by defining SERVICE_ENDPOINT and SERVICE_TOKEN in
> my own environment, which appear to be overriding the credentials provided
> on the CLI -- I don't think that's the intended behavior.
>
> If you unset them, you should be able to verify the install.
>
> If you skip verifying keystone and something is wrong with it, you'll
> likely find out pretty quick when another service calls keystone for the
> first time :)
>
> -Dolph
>
>
> On Wed, Oct 31, 2012 at 12:22 PM, Ahmed Al-Mehdi  wrote:
>
>> Hi Dolph,
>>
>> Thank you very much for helping me on this issue.  Following is the
>> environment variables related to openstack:
>>
>> root@bodega:~# env | egrep "OS_|SERVICE_"
>> SERVICE_ENDPOINT=http://10.176.20.158:35357/v2.0/
>> SERVICE_TOKEN=012345SECRET99TOKEN012345
>> root@bodega:~# ifconfig eth0
>> eth0  Link encap:Ethernet  HWaddr 00:1e:67:06:1b:67
>>   inet addr:10.176.20.158  Bcast:10.176.255.255  Mask:255.255.0.0
>>   inet6 addr: fe80::21e:67ff:fe06:1b67/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>>   RX packets:12760203 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:203944 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:1044985224 (1.0 GB)  TX bytes:22642912 (22.6 MB)
>>   Interrupt:16 Memory:b200-b202
>> root@bodega:~#
>>
>> I am attaching keystone.conf file.
>>
>> Would you happen to know if there is a high level document document on
>> keystone (more than just a user guide, but a architectural/functional doc,
>> but not a API doc).  Something similar to
>> http://docs.openstack.org/trunk/openstack-identity/admin/os-identity-starter-guide-trunk.pdf
>>  but
>> updated.
>>
>> Does my current issue prohibit me from progressing forward with the next
>> steps in the install document, setting up glance, nova, etc.?
>>
>> Regards,
>> Ahmed.
>>
>>
>>
>> From: Dolph Mathews 
>> Date: Wednesday, October 31, 2012 9:44 AM
>> To: Ahmed Al-Mehdi 
>> Cc: "openstack@lists.launchpad.net" 
>> Subject: Re: [Openstack] Verification of Keystone Installation fails
>>
>> The error you're seeing is actually client-side, so there won't be
>> anything in keystone's logs. It indicates that you're not actually
>> authenticating with keystone (and instead bypassing authentication using
>> --token and --endpoint, for example) ... however, that's obviously not the
>> case, as you're explicitly providing --os-username, etc.
>>
>> Unfortunately, I'm not able to reproduce this issue. Can you share your
>> OS_* environment variables? I suspect something there
>> is unexpectedly overriding what you're providing on the CLI... which would
>> be a legitimate bug.
>>
>> Thanks,
>>
>> -Dolph
>&

Re: [Openstack] [OpenStack] Limiting new roles

[Dolph Mathews]

With regard to keystone, the current policy implementation is entirely
binary in that a role may either have total control over keystone or none.
The implementation in Grizzly is much more granular.

-Dolph


On Wed, Oct 31, 2012 at 2:35 PM, Guillermo Alvarado <
guillermoalvarad...@gmail.com> wrote:

> Hi everyboy,
>
> I want to create a new role, named "another-admin", so this role only  can
> create tentants and roles but cannnot change quotas or modify images and
> all other actions that admin role can do.
>
> I read about create rules in the policy.json of each service (nova,
> keystone, glance, swift) but my doubt is: How can I limit the
> views/templates/urls of Horizon, I mean, I want that the role
> "another-admin" can not see templates related to glance and can not see
> that menu.
>
> Thanks in advance,
> Best Regards.
>
>
>
> ___
> 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

Re: [Openstack] Verification of Keystone Installation fails

[Dolph Mathews]

I was able to reproduce by defining SERVICE_ENDPOINT and SERVICE_TOKEN in
my own environment, which appear to be overriding the credentials provided
on the CLI -- I don't think that's the intended behavior.

If you unset them, you should be able to verify the install.

If you skip verifying keystone and something is wrong with it, you'll
likely find out pretty quick when another service calls keystone for the
first time :)

-Dolph


On Wed, Oct 31, 2012 at 12:22 PM, Ahmed Al-Mehdi  wrote:

> Hi Dolph,
>
> Thank you very much for helping me on this issue.  Following is the
> environment variables related to openstack:
>
> root@bodega:~# env | egrep "OS_|SERVICE_"
> SERVICE_ENDPOINT=http://10.176.20.158:35357/v2.0/
> SERVICE_TOKEN=012345SECRET99TOKEN012345
> root@bodega:~# ifconfig eth0
> eth0  Link encap:Ethernet  HWaddr 00:1e:67:06:1b:67
>   inet addr:10.176.20.158  Bcast:10.176.255.255  Mask:255.255.0.0
>   inet6 addr: fe80::21e:67ff:fe06:1b67/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:12760203 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:203944 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:1044985224 (1.0 GB)  TX bytes:22642912 (22.6 MB)
>   Interrupt:16 Memory:b200-b202
> root@bodega:~#
>
> I am attaching keystone.conf file.
>
> Would you happen to know if there is a high level document document on
> keystone (more than just a user guide, but a architectural/functional doc,
> but not a API doc).  Something similar to
> http://docs.openstack.org/trunk/openstack-identity/admin/os-identity-starter-guide-trunk.pdf
>  but
> updated.
>
> Does my current issue prohibit me from progressing forward with the next
> steps in the install document, setting up glance, nova, etc.?
>
> Regards,
> Ahmed.
>
>
>
> From: Dolph Mathews 
> Date: Wednesday, October 31, 2012 9:44 AM
> To: Ahmed Al-Mehdi 
> Cc: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] Verification of Keystone Installation fails
>
> The error you're seeing is actually client-side, so there won't be
> anything in keystone's logs. It indicates that you're not actually
> authenticating with keystone (and instead bypassing authentication using
> --token and --endpoint, for example) ... however, that's obviously not the
> case, as you're explicitly providing --os-username, etc.
>
> Unfortunately, I'm not able to reproduce this issue. Can you share your
> OS_* environment variables? I suspect something there
> is unexpectedly overriding what you're providing on the CLI... which would
> be a legitimate bug.
>
> Thanks,
>
> -Dolph
>
>
> On Wed, Oct 31, 2012 at 2:08 AM, Ahmed Al-Mehdi  wrote:
>
>> Hello,
>>
>> I followed the steps in the "OpenStack Install Deploy for Ubuntu" manual
>> to install Keystone.  However, when I issue the commands in section
>> "Verifying the Identity Service Installation" (
>> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/verifying-identity-install.html
>>  ),
>> I am getting the following error:
>>
>> # keystone --os-username=admin --os-password=admin  --os-auth-url=
>> http://10.176.20.158:35357/v2.0 token-get
>> 'Client' object has no attribute 'service_catalog'
>>
>> I don't see any additional info in keystone.log.  Can someone please help
>> me.
>>
>> Thank you,
>> Ahmed.
>>
>>
>> ___
>> 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

Re: [Openstack] Verification of Keystone Installation fails

[Dolph Mathews]

The error you're seeing is actually client-side, so there won't be anything
in keystone's logs. It indicates that you're not actually authenticating
with keystone (and instead bypassing authentication using --token and
--endpoint, for example) ... however, that's obviously not the case, as
you're explicitly providing --os-username, etc.

Unfortunately, I'm not able to reproduce this issue. Can you share your
OS_* environment variables? I suspect something there
is unexpectedly overriding what you're providing on the CLI... which would
be a legitimate bug.

Thanks,

-Dolph


On Wed, Oct 31, 2012 at 2:08 AM, Ahmed Al-Mehdi  wrote:

> Hello,
>
> I followed the steps in the "OpenStack Install Deploy for Ubuntu" manual
> to install Keystone.  However, when I issue the commands in section
> "Verifying the Identity Service Installation" (
> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/verifying-identity-install.html
>  ),
> I am getting the following error:
>
> # keystone --os-username=admin --os-password=admin  --os-auth-url=
> http://10.176.20.158:35357/v2.0 token-get
> 'Client' object has no attribute 'service_catalog'
>
> I don't see any additional info in keystone.log.  Can someone please help
> me.
>
> Thank you,
> Ahmed.
>
>
> ___
> 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

Re: [Openstack] [keystone] Domain Name Spaces

[Dolph Mathews]

ud Provider
> will tell their customers how they should access they system (i.e. provide
> them with any domain specification that may or may not be required).
>
>
> I think that this complicates things.  I would instead recommend that a
> provider either go with a single domain or explicit domaiuns, as mixing the
> two is wierd, but some installations will need to make their existing
> deployments work.
>
> I like the idea that the domain will be implicit from the hostname of the
> web front end, and also possibly of a Keystone endpoint.  This can be done
> with vhosts for Apache, and a simple config value for Eventlet.
>
>
>
> 
>
> ** **
>
> Very keen to hear other concerns you may have.
>
> ** **
>
> Henry
>
> On 27 Oct 2012, at 21:22, Gabriel Hurley wrote:
>
>
>
> 
>
> There are various options for how Horizon can handle the UX problems
> associated with adding additional domains. Making it a part of the URL is
> one which could be supported, but I’m not inclined to make that the only
> method. The implementation details can be hashed out when we get there.***
> *
>
>  
>
> I am more concerned about the experience for CLI/API users; adding more
> parameters they have to pass is quite unfriendly. And I have to say that
> Keystone’s track record for handling “default” options has been quite poor
> (see “default tenant”). The mixed support for lookups via ID vs. name is
> also a mess. There needs to be consistency around what is unique and in
> what scope (which is where this thread started). So far I haven’t heard a
> concrete answer on that.
>
>  
>
> For example, if tenants uniqueness is scoped to a domain, and lookups via
> tenant name are possible, and there’s a default domain… well haven’t you
> just painted yourself into a corner where tenant names in the default
> domain must be unique while names in any other domain do not? It’s these
> kinds of issues that need to really be thought through.
>
>  
>
> -  Gabriel
>
>  
>
> *From:* openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [
> mailto:openstack-bounces+gabriel.hurley=
> nebula@lists.launchpad.net] *On Behalf Of *Adam Young
> *Sent:* Friday, October 26, 2012 4:19 PM
> *To:* Henry Nash
> *Cc:* OpenStack Development Mailing List; openstack@lists.launchpad.net (
> openstack@lists.launchpad.net)
> *Subject:* Re: [Openstack] [keystone] Domain Name Spaces
>
>  
>
> On 10/26/2012 07:17 PM, Henry Nash wrote:
>
> So to pick up on a couple of the areas of contention:
>
>  
>
> a) Roles.  I agree that role names must stay globally unique.  One way of
> thinking about this is that it is not actually keystone that is creating
> the "role name space" it is the other services (Nova etc.) by specifying
> roles in their policy files.  Until those services support domain specific
> segmentation, then role names stay global.
>
>  
>
> b) Will multi-domains make it more complicated in terms of authorisation -
> e.g. will the users have to input a Domain Name into Horizon the whole
> time?  The first thing I would say is that if the cloud administrator has
> create multiple domains, then the keystone API should indeed require the
> domain specification.  However, that should not mean it should be laborious
> for a Horizon user.  In the case where a Cloud Provider has created domains
> to encapsulate each of their customers - then if they want to let those
> customer use horizon as the UI, then I would think they want to be able to
> give each customer a unique URL which will point to a Horizon that "knows
> which domain to go to".
>
> Yes, I think that this is the solution.  It will involve HTTPD virtual
> hosts, and horizon can then get an additional config parameter
> "keystone_domain" as part of the wsgi config.
>
>
>
>
> 
>
>  Maybe the url contains the Domain Name or ID in the path, and Horizon
> pulls this out of its own url (assuming that's possible) and hence the user
> is never given an option to chose a domain.  A Cloud Admin would use a "non
> domain qualified url" to get to Horizon (basically as it is now) and hence
> be able to see the different domains.  Likewise, in the case of where the
> Cloud Provider has not chosen to create any individual domains (and is just
> running the cloud in the default domain), then the  "non domain qualified
> url" would be used to a Horizon that only showed one, default domain and
> hence no choice is required.
>
>  
>
>  
>
> Henry
>
>  
>
> On 26 Oct 2012, at 17:

Re: [Openstack] Retrieve Endpoints

[Dolph Mathews]

It's hard to say without docs, as the openstack.identity.endpoint shown
there is just throwing errors for me, and the openstack.endpoint is raising
401.

However, the port used for the identity endpoint is typically used for the
administrative/management identity endpoint (keystone), and the
openstack.endpoint refers to specifically to "compute" in the hostname
(nova).

-Dolph


On Sun, Oct 28, 2012 at 11:21 PM, Tummala Pradeep <
pradeep.tumm...@ericsson.com> wrote:

>  Hi Joe,
>
> I am actually trying to integrate cloudify with Openstack. To accomplish
> this, I have to configure openstack.groovy file in cloudify.
>
> There are two fields here - openstack.endpoint &
> openstack.identity.endpoint. I have an example for cloudify integration
> with HP Openstack cloud. Hope, it will help you to understand what exactly
> these two fields (Last 4 lines) require.
>
>   
>   cloud {
>
>   // Mandatory. The name of the cloud, as it will appear in the Cloudify 
> UI.
>   name = "Openstack"
>   configuration {
>   // Mandatory - openstack Diablo cloud driver.
>   className 
> "org.cloudifysource.esc.driver.provisioning.openstack.OpenstackCloudDriver"
>   // Optional. The template name for the management machines. 
> Defaults to the first template in the templates section below.
>   managementMachineTemplate "SMALL_LINUX"
>   **// Optional. Indicates whether internal cluster 
> communications should use the machine private IP. Defaults to true.
>   connectToPrivateIp true
>remoteUsername "REPLACE_WITH_THE_SSH_USER_NAME"
>remotePassword "REPLACE_WITH_THE_SS_USER_PASSWORD"
>   }
>   provider {
>   // optional
>   provider "openstack"
>   localDirectory "tools/cli/plugins/esc/hp/upload"
>   remoteDirectory "/root/gs-files"
>   cloudifyUrl 
> "http://s3.amazonaws.com/gigaspaces-cloudify/cloudify/hp/gigaspaces-hp.zip"; 
> 
>   machineNamePrefix "agent"
>   dedicatedManagementMachines true
>   managementOnlyFiles ([])
>   managementGroup "management"
>   numberOfManagementMachines 1
>   zones (["agent"])
>   reservedMemoryCapacityPerMachineInMB 1024
>   }
>   user {
>   user "ENTER_USER"
>   apiKey "ENTER_KEY"
>   keyFile "ENTER_KEY_FILE"
>   }
>   templates ([
>   SMALL_LINUX : template{
>   imageId "221"
>   machineMemoryMB 1600
>   
>   hardwareId "102"
>   //locationId "us-east-1"
>   options ([
>   "openstack.securityGroup" : 
> "test",
>   "openstack.keyPair" : 
> "hp-cloud-demo",
>   // indicates if a floating IP 
> should be assigned to this machine. Defaults to true.
>   
> "openstack.allocate-floating-ip" : "true"
>   ])
>   }
>   ])
>   custom ([
>   *"openstack.endpoint" : 
> "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/"; 
> ,*
> * "openstack.identity.endpoint": 
> "https://region-a.geo-1.identity.hpcloudsvc.com:35357/"; 
> ,*
>   "openstack.tenant" : "ENTER_TENANT",
>   "openstack.wireLog": "false"
>   ])
> }
>
> Now, I am trying the integration with OpenStack deployed on my server. Do
> let me know if you get any idea from the above example.
>
> Thanks
>
> Pradeep
>
>
> On 10/26/2012 01:36 AM, heckj wrote:
>
> Hi Pradeep,
>
> I'm not sure what the context is for these values, so it's a little hard to 
> assert a clear answer.
>
> For most openstack projects, (all but keystone), there's generally a single 
> API endpoints, and the keystone service catalog is configured on deployment 
> to point to those. The service catalog supports exposing internal and public 
> endpoints.
>
> Keystone (quirky thing that it is) has two endpoints - one for general public 
> authorization with a very limited API - in the docs and on the CLI, this is 
> referred to as the "auth_url". In a devstack setup, this auth_url is 
> "http://localhost:5000/v2.0";  - your deployment 
> I'd expect to be different.
>
> There's also an administrative endpoint for Keystone where a Keystone admin 
> (or associated scripts) can configure services, endpoints, users, etc 
> depending on the keystone 

Re: [Openstack] documentation bug in openstack - redhat install guide (wrong admin_user)

[Dolph Mathews]

Thanks for the feedback! I opened a bug report to track this issue:
https://bugs.launchpad.net/openstack-manuals/+bug/1071921

-Dolph


On Fri, Oct 26, 2012 at 4:03 PM, ikke  wrote:

> Hi,
>
> I just went through setting up keystone and glance to fedora 17 with
> f18 folsom preview repos for openstack rpms. It seems the instructions
> have some error:
>
> it creates the users here:
>
> http://docs.openstack.org/trunk/openstack-compute/install/yum/content/setting-up-tenants-users-and-roles-manually.html
>
> and uses them incorrectly here, causing keystone to block access to
> create-image:
>
>
> http://docs.openstack.org/trunk/openstack-compute/install/yum/content/configure-glance-files.html
>
> doc uses admin_user=admin, admin_tenant=service in two of the config
> files (api+registry), even though it never created admin user for the
> tenant service in the first doc link where the users get created.
>
> After changing the admin_user to glance and also admin_password to
> glance's password, it starts working.
>
> There used to be comment box in the docs, but it doesn't seem to be
> the case anymore. So I'll whine here instead ;)
>
> BR,
>
>  ikke
>
> ___
> 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

Re: [Openstack] Tracking triage statistics

[Dolph Mathews]

How many cookies for a self-triaged bug that was subsequently closed as
invalid? This rulebook is going to get really complicated really fast ;)

Would love to see a report for more projects on a longer timeline!

-Dolph


On Fri, Oct 26, 2012 at 7:42 AM, Thierry Carrez wrote:

> Michael Still wrote:
> > Report (a * after the bug id indicates self triage):
> >   Chuck Short: 6 (1065211, 1065848, 1066213, 1066254, 1066845, 1068539)
> >   Dan Prince: 1 (1070509*)
> >   Michael Still: 6 (1062474, 1070349, 1064854, 1065728*, 1065430,
> 1070452)
> >   Mauro Sergio Martins Rodrigues: 16 (1070155*, 1070156*, 1070157*,
> > 1070158*, 1070160*, 1070161*, 1070162*, 1070163*, 1070164*, 1070165*,
> > 1070167*, 1070169*, 1070170*, 1070171*, 1070172*, 1070173*)
> >   Matthew Treinish: 1 (1071338*)
> >   Russell Bryant: 1 (1067858*)
> >   Vish Ishaya: 9 (1071017, 1071547, 1053814, 1066887, 1067638, 1067744,
> > 1068154, 1071069, 1071462)
> >
> > So, you get the cookie, but people know about it too.
>
> How about half a cookie for self-triaging ?
>
> Great stuff!
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> ___
> 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

Re: [Openstack] ERROR: string indices must be integers, not str

[Dolph Mathews]

Sorry for the delayed response; I know I've seen this message before. I
believe it had something to do with endpoints configured in a manner
keystone did not expect. Can you paste the full backtrace from the logs,
and if it appears to be related, your keystone endpoint-list?

-Dolph


On Thu, Oct 18, 2012 at 5:00 AM, Xu, HongnaX  wrote:

> Hi
>   I am installing openstack on ubuntu 12.10 beta2 with
> precise-updates/folsom repo , after sync keystone database, then these
> parameters in ~/.bashrc
>
> export SERVICE_TOKEN=admin
> export OS_TENANT_NAME=admin
> export OS_USERNAME=admin
> export OS_PASSWORD=openstack
> export OS_AUTH_URL=http://10.211.55.17:5000/v2.0/
> export SERVICE_ENDPOINT=http://10.211.55.17:35357/v2.0/
>
> when I add keystone users by "keystone user-create --name admin --pass
> openstack --email ad...@foobar.com" or "keystone user-list", I got string
> indices must be integers, not str, is there any solution? My settings
> exactly the same as the wiki
> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ap_installingfolsomubuntuprecise.html
>
>
> Best Regards,
> Hongna
>
>
>
> ___
> 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

Re: [Openstack] A simple guide to install OpenStack Folsom

[Dolph Mathews]

I played around with the idea this afternoon, and settled on something as
simple as this in keystoneclient rather than keystone-manage:

$ keystone help bootstrap
usage: keystone bootstrap [--user-name ] --pass 
  [--role-name ]
  [--tenant-name ]

Grants a new role to a new user on a new tenant, after creating each.

Optional arguments:
  --user-name 
The name of the user to be created
(default="admin").
  --pass 
The password for the new user.
  --role-name 
The name of the role to be created and granted to
the user (default="admin").
  --tenant-name 
The name of the tenant to be
created (default="admin").

Example usage:

$ keystone-manage db_sync

$ keystone-all

$ keystone --token=ADMIN --endpoint=http://localhost:35357/v2.0/ *bootstrap*
 --pass=secrete

$ keystone --os-username=admin --os-password=secrete --os-tenant-name=admin
--os-auth-url=http://localhost:35357/v2.0/ token-get

+---+--+

|  Property |  Value   |

+---+--+

|  expires  |   2012-10-11T22:25:02Z   |

| id| 4ae78bd2cd9049888060d07acddf88d1 |

| tenant_id | 8fbba4f7f77e4acb80d746c65f20882b |

|  user_id  | d8e31d9a341243a2bb8d575707a273ea |
+---+--+

The same "shortcut" idea could apply to other extremely common usage
patterns on the CLI (e.g. registering a service *and* all of it's endpoints
in a single CLI command), thus eliminating most of the complexity of basic
setup scripts like sample_data.sh and it's variants.

I also put this up for review: https://review.openstack.org/#/c/14314

-Dolph


On Wed, Oct 10, 2012 at 1:15 PM, Joshua Harlow wrote:

> That sounds great to me. I can help out in converting this code into that
> code.
>
> It seems like a trivial kind of thing to do, what format would that
> command take, a yaml file?
>
> Something similar to
> https://github.com/yahoo/Openstack-Anvil/blob/master/conf/templates/keystone/init_what.yaml
>  maybe,
> idk.
>
> From: Dolph Mathews 
> Date: Wednesday, October 10, 2012 11:13 AM
> To: Joshua Harlow 
> Cc: Alan Pevec , Skible OpenStack <
> skible.openst...@gmail.com>, "openstack@lists.launchpad.net" <
> openstack@lists.launchpad.net>
> Subject: Re: [Openstack] A simple guide to install OpenStack Folsom
>
> I'd like to simplify the scope of sample_data.sh to the absolute bare
> minimum (service tenant, admin role, admin user, identity
> service/endpoints, etc), and integrate it into keystone-manage as a
> 'bootstrap' command:
>
> $ keystone-manage bootstrap
>
> -Dolph
>
>
> On Wed, Oct 10, 2012 at 12:34 PM, Joshua Harlow wrote:
>
>> You guys should also consider the 'anvil' way of doing this (pure python
>> baby, haha).
>>
>> Which is improved from lorin's and has been working for yahoo! for a while
>> now.
>>
>>
>> https://github.com/yahoo/Openstack-Anvil/blob/master/anvil/components/helpe
>> rs/keystone.py#L25<https://github.com/yahoo/Openstack-Anvil/blob/master/anvil/components/helpers/keystone.py#L25>
>>
>> Please feel free to take the code!! Its only 'real' dependency is the
>> keystone client + yaml parsing...
>>
>> On 10/10/12 2:23 AM, "Alan Pevec"  wrote:
>>
>> >On Wed, Oct 10, 2012 at 11:10 AM, Skible OpenStack
>> > wrote:
>> >> I am counting on our your feedback to enhance my work and contribute it
>> >>to
>> >> the OpenStack Eco System.
>> >
>> >I wonder about
>> >
>> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/tree/master/
>> >Scripts
>> >which say:
>> ># Mainly inspired by
>> >https://github.com/openstack/keystone/blob/master/tools/sample_data.sh
>> >
>> >Why not submit that as an improvement to Keystone?
>> >I'd like to propose consolidation of all keystone initialization
>> >scripts around (Keyston's sample_data.sh, Devstack's keystone_data.sh,
>> >scripts like yours) and  move to Lorin's YAML config (see
>> >https://lists.launchpad.net/openstack/msg17204.html)
>> >I'm just not sure yet if additional dependency on YAML is worth it.
>> >
>> >Cheers,
>> >Alan
>> >
>> >___
>> >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

Re: [Openstack] A simple guide to install OpenStack Folsom

[Dolph Mathews]

I'd like to simplify the scope of sample_data.sh to the absolute bare
minimum (service tenant, admin role, admin user, identity
service/endpoints, etc), and integrate it into keystone-manage as a
'bootstrap' command:

$ keystone-manage bootstrap

-Dolph


On Wed, Oct 10, 2012 at 12:34 PM, Joshua Harlow wrote:

> You guys should also consider the 'anvil' way of doing this (pure python
> baby, haha).
>
> Which is improved from lorin's and has been working for yahoo! for a while
> now.
>
> https://github.com/yahoo/Openstack-Anvil/blob/master/anvil/components/helpe
> rs/keystone.py#L25
>
> Please feel free to take the code!! Its only 'real' dependency is the
> keystone client + yaml parsing...
>
> On 10/10/12 2:23 AM, "Alan Pevec"  wrote:
>
> >On Wed, Oct 10, 2012 at 11:10 AM, Skible OpenStack
> > wrote:
> >> I am counting on our your feedback to enhance my work and contribute it
> >>to
> >> the OpenStack Eco System.
> >
> >I wonder about
> >
> https://github.com/mseknibilel/OpenStack-Folsom-Install-guide/tree/master/
> >Scripts
> >which say:
> ># Mainly inspired by
> >https://github.com/openstack/keystone/blob/master/tools/sample_data.sh
> >
> >Why not submit that as an improvement to Keystone?
> >I'd like to propose consolidation of all keystone initialization
> >scripts around (Keyston's sample_data.sh, Devstack's keystone_data.sh,
> >scripts like yours) and  move to Lorin's YAML config (see
> >https://lists.launchpad.net/openstack/msg17204.html)
> >I'm just not sure yet if additional dependency on YAML is worth it.
> >
> >Cheers,
> >Alan
> >
> >___
> >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

Re: [Openstack] No proper displau with Horizon

[Dolph Mathews]

Hmm... I don't see anything wrong there. Any chance you've
overridden AVAILABLE_REGIONS in your horizon configuration? If so, what's
the new value?

Also, to make sure service_id references are configured correctly, can you
paste the raw output of:

curl http://x.x.x.x:35357/v2.0/endpoints -H 'x-auth-token: ADMIN'

Substitute your own IP for keystone and a valid token.

-Dolph


On Mon, Oct 8, 2012 at 3:47 AM, Bilel Msekni  wrote:

>  Thanks for replying Dolph:
>
>
> keystone service-list
>
> +--+--+--+--+
> |id|   name   |   type   |
> description  |
>
> +--+--+--+--+
> | 020a5c2b03074e89972202f3822fa95f | quantum  | network  | OpenStack
> Networking service |
> | 2b3d91dd9110493a92ea5eb7909d41cf |   ec2|   ec2|OpenStack
> EC2 service |
> | 4ef30c360f4e4e0aaac9d1247dcaafe8 |  cinder  |  volume  |   OpenStack
> Volume Service   |
> | 776d3b71749f4711bf1c956ccfeb2728 |  glance  |  image   |   OpenStack
> Image Service|
> | 9733c366161f4f7f8e8484fe702ee840 | keystone | identity |  OpenStack
> Identity  |
> | c6011214a82645fe97b4bbd64608ad9b |   nova   | compute  |  OpenStack
> Compute Service   |
>
> +--+--+--+--+
>
> keystone endpoint-list
>
> +--+---+--+--+--+
> |id|   region  |
> publicurl   | internalurl
> |   adminurl   |
>
> +--+---+--+--+--+
> | 2febceec3f324755b0c9c7fe3ba2d29d | RegionOne |
> http://x.x.x.x:9696/ | http://x.x.x.x:9696/
> | http://x.x.x.x:9696/ |
> | 649d5e5b5cd8467c89b218b2adc29009 | RegionOne |
> http://x.x.x.x:8774/v2/$(tenant_id)s |
> http://x.x.x.x:8774/v2/$(tenant_id)s |
> http://x.x.x.x:8774/v2/$(tenant_id)s |
> | 7b25b6283dd4408d8c8f7541b9b9d2f0 | RegionOne |
> http://x.x.x.x:5000/v2.0   |   http://x.x.x.x:5000/v2.0
> |  http://x.x.x.x:35357/v2.0   |
> | 9ebfa2784d78425fa08a146aa27e786b | RegionOne |
> http://x.x.x.x:9292/v2|http://x.x.x.x:9292/v2
> |http://x.x.x.x:9292/v2|
> | f321ae42d39d4d9a9d5e771be459f6ba | RegionOne |
> http://x.x.x.x:8776/v1/$(tenant_id)s |
> http://x.x.x.x:8776/v1/$(tenant_id)s |
> http://x.x.x.x:8776/v1/$(tenant_id)s |
> | f7ef924364614d91b49a589ca7719ce6 | RegionOne |
> http://x.x.x.x:8773/services/Cloud  |  http://x.x.x.x:8773/services/Cloud
> |  http://x.x.x.x:8773/services/Admin  |
>
> +--+---+----------+--+--+
>
> x.x.x.x refers to my Host address :)
>
>
>
> Le 08/10/2012 10:18, Dolph Mathews a écrit :
>
> "it seems like it is looking for an endpoint which are all there" are you
> sure? -- it looks like your service catalog is missing the 'identity'
> service entirely... can you paste the output of the following two
> commands?:
>
>  $ keystone service-list
> $ keystone endpoint-list
>
>  -Dolph
>
>
> On Mon, Oct 8, 2012 at 2:59 AM, Bilel Msekni  wrote:
>
>>  Good day everyone,
>>
>> I have installed OpenStack Folsom successfully but i am experiencing a
>> wierd bug in the dashboard: It's not giving me any proper display.
>> This is the error log i got from apache, http://pastebin.com/P44Edku5
>>  it seems like it is looking for an endpoint which are all there and
>> working fine.
>>
>> P.S: I used this script to populate my database
>>
>> ===
>>
>> create_endpoint () {
>>   case $1 in
>> compute)
>> keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 
>> --publicurl 'http://'"$MASTER"':8774/v2/$(tenant_id)s' --adminurl 
>> 'http://'"$MASTER"':8774/v2/$(tenant_id)s' --internalurl 
>> 'http://'"$MASTER"':8774/v2/$(tenant_id)s'
>> ;;
>> volume)
>> keystone endpoint-create --region $KEYSTONE_R

Re: [Openstack] Question about Keystone RBAC

[Dolph Mathews]

That will provided by Identity API v3, currently in draft:
https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md

The "when" is first dependent on:

1) Identity API v3 support in keystone
https://review.openstack.org/#/c/12106/
2) Identity API v3 support in keystoneclient
https://review.openstack.org/#/c/12806/
3) services need to consume the centralized policy info, probably through
common middleware
4) adding UI support in horizon

An open question: are you looking to modify policy per service or do you
need policy granularity per endpoint?

-Dolph


On Wed, Oct 3, 2012 at 7:29 PM, Shake Chen  wrote:

> Hi
>
> I also have question about RBAC.
>
> when we can setting the roles permission in Horizon?
>
>
> On Thu, Oct 4, 2012 at 2:56 AM, Dolph Mathews  > wrote:
>
>>  (replying on list)
>>
>>  RBAC policy enforce is already implemented on consuming services and
>> default policies are provided by policy.json files (e.g.
>> https://github.com/openstack/nova/blob/master/etc/nova/policy.json ).
>>
>>  We haven't yet implemented a method for services to consume policy
>> blobs from Identity API v3, /v3/policies (which itself is still in
>> development), rather than loading policy.json files.
>>
>>  For an example of scoping RBAC per project, see the admin_or_owner rule
>> in nova's policy.json above.
>>
>>  As for the efficiency of policy storage, I'm not clear on what your
>> concerns are?
>>
>>  -Dolph
>>   --
>> *From:* MS. Faraji [ms.far...@utoronto.ca]
>> *Sent:* Wednesday, October 03, 2012 1:34 PM
>> *To:* Dolph Mathews
>> *Subject:* Question about Keystone RBAC
>>
>>   Hi,
>>
>> I sent an email to inquire about RBAC implementation in Keystone before,
>> and you generously shared your information. However, there are a couple of
>> questions that I have in mind.
>> I searched the Internet and documents; however, I did not find useful
>> information about them. I hope you can help me to find it out.
>>
>> 1) Consider the enforce API is implemented, which side should use it?
>> Service or Keystone itself. If Keystone uses this function, how does it
>> know about the action that a user
>> wants to perform on a resource. If service call it as an API, what is the
>> endpoint? How services use authorization in Keystone?
>>
>> 2) Can roles and associated actions be defined in the scope of project or
>> domain? For example demo can do release in project 1 but not in project 2.
>>
>> 3) Is the plain storage of capabilities ( no data structure) efficient?
>> In terms of required storage space and later lookups.
>>
>> Thanks in advance for your help and assistance,
>> I look forward to your response.
>>
>>
>> Moh,
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Shake Chen
>
>
>
> ___
> 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

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

The "scripted configuration" openstack-manuals currently refers to (written
by Lorin, CC'd here): https://github.com/nimbis/keystone-init

Bugs in openstack-manuals don't really apply there :-/

I can't argue with having a scripted solution -- that's great, no doubt.
However, I assume that making the scripted solution first and foremost in
the manual leads most users to blindly run the script, bypassing the
educational portion of the manual. Beyond that, the docs use the CLI, and
the linked script uses the Python API directly, which means it will be
difficult for most users to follow them both, side by side.

At the very least, I'd like to move this approach to the end of the page;
and ideally, the script would be managed by openstack.

-Dolph

On Tue, Oct 2, 2012 at 7:19 PM, Anne Gentle  wrote:

> Comments below. With an "I object." :)
>
> On Tue, Oct 2, 2012 at 6:50 PM, Dolph Mathews wrote:
>
>> I find it odd that the document describes two approaches for configuring
>> keystone -- one being a relatively undocumented, scripted approach not
>> managed or distributed by OpenStack. Surely these two approaches will
>> continue to evolve seperately and we'll experience more issues such as this
>> one.
>>
>> Anyone have any objections to removing this "scripted configuration"
>> section in favor of focusing on the existing "manual" approach?
>>
>
> Sorry, I have to object after watching this page and the scripts evolve
> over the last 9-12 months. There just has to be a scripted option and I
> agree it needs to be tested and maintained. I'm fine with having the
> keystone script be the documented one. For a while though the scripts were
> populating templated catalogs (files) not populating the database.
>
> I think the best fix is to:
>  - ensure scripts have exactly the documented names of tenants, users, etc.
>  - patch the doc to use only the names in the script and manual in the
> verification step.
>
> Doc bug logged here describing the work needing done:
> https://bugs.launchpad.net/openstack-manuals/+bug/1060536
>
>
>
>>
>> http://docs.openstack.org/trunk/openstack-compute/install/apt/content/setting-up-tenants-users-and-roles.html
>>
>> -Dolph
>>
>>
>> On Tue, Oct 2, 2012 at 6:42 PM, Ahmed Al-Mehdi  wrote:
>>
>>>   Hi Dolph,
>>>
>>>  I am now getting the same output as the "curl" command, basically
>>> "Invalid Tenant". At this point
>>>
>>> root@ubuntu1:~# keystone --os-username=adminUser --os
>>> -password=secretword --os-tenant-name=service --os-auth-url=http://10.0.
>>> 2.15:35357/v2.0 token-get
>>>
>>> No handlers could be found for logger "keystoneclient.client"
>>> Invalid tenant (HTTP 401)
>>>
>>> Without the "os-tenant-name" parameter, I seem to get "good' response.
>>>
>>> root@ubuntu1:~# keystone --os-username=adminUser --os
>>> -password=secretword --os-auth-url=http://10.0.2.15:35357/v2.0 token-get
>>> No handlers could be found for logger "keystoneclient.v2_0.client"
>>> +--+--+
>>> | Property | Value |
>>> +--+--+
>>> | expires | 2012-10-03T23:31:17Z |
>>> | id | 31078072aae94f5aab5c8e46ff5f6373 |
>>> | user_id | 3e674f7f64ba452cb20781b8d5e26b7f |
>>> +--+--+
>>>  At this point, I feel like I am running into issues with/in the python
>>> / PyYAML script (https://github.com/nimbis/keystone-init.git) which
>>> must not be populating info into keystone "accurately" and most probably
>>> not equivalent to manual steps mentioned in "Deploy and Install
>>> OpenStack - Red Hat Ubuntu". I will look into the script.
>>>
>>>  Regards,
>>> Ahmed.
>>>
>>>  --
>>> *From:* Dolph Mathews [dolph.math...@gmail.com]
>>> *Sent:* Tuesday, October 02, 2012 2:19 PM
>>>
>>> *To:* Ahmed Al-Mehdi
>>> *Cc:* heckj; openstack@lists.launchpad.net
>>> *Subject:* Re: [Openstack] Enabling logging in keystone.
>>>
>>>  No worries, that's what a second set of eyes is for!
>>>
>>>  By specifying a token and endpoint, you're bypassing the
>>> authentication process that your curl command is performing.
>>>
>>>  You can test authentication with the keystone client using:
>>>
>>>  $ keystone --os-username=adminUser --o

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

blicURL": "
> http://10.0.2.15:8776/v1/07a44f9d55694d638f41bc160c14b42e";,
> "region": "RegionOne"
> }
> ],
> "endpoints_links": [],
> "name": "volume",
> "type": "volume"
> },
> {
> "endpoints": [
> {
> "adminURL": "http://10.0.2.15:8773/services/Admin
> ",
> "id": "3efbabfc7e634bb0ac779a1e39ce385a",
> "internalURL": "
> http://10.0.2.15:8773/services/Cloud";,
> "publicURL": "http://10.0.2.15:8773/services/Cloud
> ",
> "region": "RegionOne"
> }
> ],
> "endpoints_links": [],
> "name": "ec2",
> "type": "ec2"
> },
> {
> "endpoints": [
> {
> "adminURL": "http://10.0.2.15:/v1";,
> "id": "1bf33c68cd70421797f05b55349abddc",
> "internalURL": "
> http://10.0.2.15:/v1/AUTH_07a44f9d55694d638f41bc160c14b42e";,
> "publicURL": "
> http://10.0.2.15:/v1/AUTH_07a44f9d55694d638f41bc160c14b42e";,
> "region": "RegionOne"
> }
> ],
> "endpoints_links": [],
> "name": "swift",
> "type": "object-store"
> },
> {
> "endpoints": [
> {
> "adminURL": "http://10.0.2.15:35357/v2.0";,
> "id": "ca29bb2a675d4f52bd0c8f0b0d163795",
> "internalURL": "http://10.0.2.15:5000/v2.0";,
> "publicURL": "http://10.0.2.15:5000/v2.0";,
> "region": "RegionOne"
> }
> ],
> "endpoints_links": [],
> "name": "keystone",
> "type": "identity"
> }
> ],
> "token": {
> "expires": "2012-10-04T06:03:49Z",
> "id": "1320c1df67eb4519b3545b91bdaa1f05",
> "tenant": {
> "description": "Default Tenant",
> "enabled": true,
> "id": "07a44f9d55694d638f41bc160c14b42e",
> "name": "openstackDemo"
> }
> },
> "user": {
> "id": "3e674f7f64ba452cb20781b8d5e26b7f",
> "name": "adminUser",
> "roles": [
> {
> "name": "admin"
> }
> ],
> "roles_links": [],
> "username": "adminUser"
> }
> }
> }
>
> Thank you,
> Ahmed.
>
>
>
>
>  --
> *From:* 
> openstack-bounces+ahmed=coraid@lists.launchpad.net[openstack-bounces+ahmed=
> coraid@lists.launchpad.net] On Behalf Of Ahmed Al-Mehdi [
> ah...@coraid.com]
> *Sent:* Tuesday, October 02, 2012 4:42 PM
> *To:* Dolph Mathews
>
> *Cc:* openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Enabling logging in keystone.
>
>Hi Dolph,
>
>  I am now getting the same output as the "curl" command, basically
> "Invalid Tenant". At this point
>
> root@ubuntu1:~# keystone --os-username=adminUser 
> --os-password=secretword--os-tenant-name=service
> --os-auth-url=http://10.0.
> 2.15:35357/v2.0 token-get
> No handlers could be found for logger "keystoneclient.client"
> Invalid tenant (HTTP 401)
>
> Without the "os-tenant-name" parameter, I seem to get "good' response.
>
> root@ubuntu1:~# keystone --os-username=adminUser --os-password=secretword--os
> -auth-url=http://10.0.2.15:35357/

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

I find it odd that the document describes two approaches for configuring
keystone -- one being a relatively undocumented, scripted approach not
managed or distributed by OpenStack. Surely these two approaches will
continue to evolve seperately and we'll experience more issues such as this
one.

Anyone have any objections to removing this "scripted configuration"
section in favor of focusing on the existing "manual" approach?

http://docs.openstack.org/trunk/openstack-compute/install/apt/content/setting-up-tenants-users-and-roles.html

-Dolph


On Tue, Oct 2, 2012 at 6:42 PM, Ahmed Al-Mehdi  wrote:

>   Hi Dolph,
>
>  I am now getting the same output as the "curl" command, basically
> "Invalid Tenant". At this point
>
> root@ubuntu1:~# keystone --os-username=adminUser 
> --os-password=secretword--os-tenant-name=service
> --os-auth-url=http://10.0.
> 2.15:35357/v2.0 token-get
>
> No handlers could be found for logger "keystoneclient.client"
> Invalid tenant (HTTP 401)
>
> Without the "os-tenant-name" parameter, I seem to get "good' response.
>
> root@ubuntu1:~# keystone --os-username=adminUser --os-password=secretword--os
> -auth-url=http://10.0.2.15:35357/v2.0 token-get
> No handlers could be found for logger "keystoneclient.v2_0.client"
> +--+--+
> | Property | Value |
> +--+--+
> | expires | 2012-10-03T23:31:17Z |
> | id | 31078072aae94f5aab5c8e46ff5f6373 |
> | user_id | 3e674f7f64ba452cb20781b8d5e26b7f |
> +--+--+
>  At this point, I feel like I am running into issues with/in the python /
> PyYAML script (https://github.com/nimbis/keystone-init.git) which must
> not be populating info into keystone "accurately" and most probably not
> equivalent to manual steps mentioned in "Deploy and Install OpenStack -
> Red Hat Ubuntu". I will look into the script.
>
>  Regards,
> Ahmed.
>
>  --
> *From:* Dolph Mathews [dolph.math...@gmail.com]
> *Sent:* Tuesday, October 02, 2012 2:19 PM
>
> *To:* Ahmed Al-Mehdi
> *Cc:* heckj; openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] Enabling logging in keystone.
>
>  No worries, that's what a second set of eyes is for!
>
>  By specifying a token and endpoint, you're bypassing the authentication
> process that your curl command is performing.
>
>  You can test authentication with the keystone client using:
>
>  $ keystone --os-username=adminUser --os-password=secretword
> --os-tenant-name=adminTenant 
> --os-authurl=http://10.0.2.15:35357/v2.0<http://10.0.2.15:35357/v2.0/tokens>
>  token-get
>
>  But as Anne pointed out, you don't have a tenant named "adminTenant".
> You'll also need to make sure you've granted a role to your user on the
> specified tenant for authorization to succeed. You can remove the tenant
> name argument from the token-get call to test authentication without
> authorization (therefore without requiring anything but a valid user in
> your keystone install).
>
>  -Dolph
>
> On Tuesday, October 2, 2012, Ahmed Al-Mehdi wrote:
>
>>  Hi Dolph,
>>
>> Very sorry about that.  With the correct token, calling keystone from
>> the cli is working.However, the curl command is failing.  Will this
>> cause an issue down the line as I start to install glance and nova?
>>
>>
>> #> keystone --token 012345SECRET99TOKEN012345 --endpoint
>> http://10.0.2.15:35357/v2.0 tenant-list
>> +--+---+-+
>> |id|  name | enabled |
>> +--+---+-+
>> | 07a44f9d55694d638f41bc160c14b42e | openstackDemo |   True  |
>> | 0e4cc20586ae42329db51e0c6f807731 |service|   True  |
>> +--+---+-+
>>  #> curl -d '{"auth": {"tenantName": "adminTenant", "passwordCredentials":
>> {"username": "adminUser", "password": "secretword"}}}' -H "Content-type:
>> application/json" http://10.0.2.15:35357/v2.0/tokens | python -mjson.tool
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>> Current
>>  Dload  Upload   Total   SpentLeft
>> Speed
>> 100   2310   116  100   115   2771   2747 --:--:-- --:--:-- --:--:--
>> 3052
>> {
>> "error": {
>> "code"

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

Feel free to file a bug -- I'm reviewing the document right now.


http://docs.openstack.org/trunk/openstack-compute/install/apt/content/verifying-identity-install.html

As for the invalid tenant message, I'm guessing you don't have any roles
granted to "adminUser" on that tenant. Checkout the user-role-add command:

$ keystone help user-role-add

You might also try the other tenant returned by tenant-list.

-Dolph


On Tue, Oct 2, 2012 at 5:48 PM, Ahmed Al-Mehdi  wrote:

>   Hi Anne,
>
>  Thank you for pointing that out. I noticed the "adminTenant" string in
> the curl command, and it did bother me a bit, but I did not pursue it due
> to lack of experience with curl / Rest API / OpenStack but looking, I
> should have known better. Can this be addressed in the "Deploy and
> Install OpenStack - Red Hat Ubuntu" document, as I am sure others might
> be running into the same issue. Do I need to file a bug against
> documentation or email someone specifically.
>
> After making the change in the curl command, I am now getting a different
> error message:
>
> #> keystone --token 012345SECRET99TOKEN012345 --endpoint
> http://10.0.2.15:35357/v2.0 tenant-list
> +--+---+-+
> | id | name | enabled |
> +--+---+-+
> | 07a44f9d55694d638f41bc160c14b42e | openstackDemo | True |
> | 0e4cc20586ae42329db51e0c6f807731 | service | True |
> +--+---+-+
>
> #> curl -d '{"auth": {"tenantName": "service", "passwordCredentials":
> {"username": "adminUser", "password": "secretword"}}}' -H "Content-type:
> application/json" http://10.0.2.15:35357/v2.0/tokens | python -mjson.tool
>% Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100   191080  100   111346480 --:--:-- --:--:-- --:--:--
> 497
> {
> "error": {
> "code": 401,
> "message": "Invalid tenant",
> "title": "Not Authorized"
> }
> }
>
>  Thank you,
> Ahmed.
>
>   --
> *From:* annegen...@justwriteclick.com [annegen...@justwriteclick.com] On
> Behalf Of Anne Gentle [a...@openstack.org]
> *Sent:* Tuesday, October 02, 2012 1:26 PM
> *To:* Ahmed Al-Mehdi
> *Cc:* Dolph Mathews; openstack@lists.launchpad.net
>
> *Subject:* Re: [Openstack] Enabling logging in keystone.
>
>  Hi Ahmed -
>
> I believe you don't have a tenant named "adminTenant" - possibly try this?
>
> curl -d '{"auth": {"tenantName": "service", "passwordCredentials":
> {"username": "adminUser", "password": "secretword"}}}' -H "Content-type:
> application/json" http://10.0.2.15:35357/v2.0/tokens | python -mjson.tool
>
> Also, you can run keystone with the --debug parameter to see the curl
> output like so:
> keystone --debug --token
> 012345SECRET99TOKEN012345 --endpoint http://10.0.2.15:35357/v2.0tenant-list
>
> Generally, yes, you need to ensure keystone is working correctly before
> installing glance and nova (they require keystone), so you're correct to
> keep trying.
>
> Anne
>
> On Tue, Oct 2, 2012 at 3:09 PM, Ahmed Al-Mehdi  wrote:
>
>>  Hi Dolph,
>>
>> Very sorry about that.  With the correct token, calling keystone from
>> the cli is working.However, the curl command is failing.  Will this
>> cause an issue down the line as I start to install glance and nova?
>>
>>
>> #> keystone --token 012345SECRET99TOKEN012345 --endpoint
>> http://10.0.2.15:35357/v2.0 tenant-list
>> +--+---+-+
>> |id|  name | enabled |
>> +--+---+-+
>> | 07a44f9d55694d638f41bc160c14b42e | openstackDemo |   True  |
>> | 0e4cc20586ae42329db51e0c6f807731 |service|   True  |
>> +--+---+-+
>>  #> curl -d '{"auth": {"tenantName": "adminTenant", "passwordCredentials":
>> {"username": "adminUser", "password": "secretword"}}}' -H "Content-type:
>> application/json" http://10.0.2.15:35357/v2.0/tokens | python
>> -mjson.tool
>>
>>   % Total 

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

No worries, that's what a second set of eyes is for!

By specifying a token and endpoint, you're bypassing the authentication
process that your curl command is performing.

You can test authentication with the keystone client using:

$ keystone --os-username=adminUser --os-password=secretword
--os-tenant-name=adminTenant
--os-authurl=http://10.0.2.15:35357/v2.0<http://10.0.2.15:35357/v2.0/tokens>
 token-get

But as Anne pointed out, you don't have a tenant named "adminTenant".
You'll also need to make sure you've granted a role to your user on the
specified tenant for authorization to succeed. You can remove the tenant
name argument from the token-get call to test authentication without
authorization (therefore without requiring anything but a valid user in
your keystone install).

-Dolph

On Tuesday, October 2, 2012, Ahmed Al-Mehdi wrote:

>  Hi Dolph,
>
> Very sorry about that.  With the correct token, calling keystone from
> the cli is working.However, the curl command is failing.  Will this
> cause an issue down the line as I start to install glance and nova?
>
>
> #> keystone --token 012345SECRET99TOKEN012345 --endpoint
> http://10.0.2.15:35357/v2.0 tenant-list
> +--+---+-+
> |id|  name | enabled |
> +--+---+-+
> | 07a44f9d55694d638f41bc160c14b42e | openstackDemo |   True  |
> | 0e4cc20586ae42329db51e0c6f807731 |service|   True  |
> +--+---+-+
>  #> curl -d '{"auth": {"tenantName": "adminTenant", "passwordCredentials":
> {"username": "adminUser", "password": "secretword"}}}' -H "Content-type:
> application/json" http://10.0.2.15:35357/v2.0/tokens | python -mjson.tool
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100   2310   116  100   115   2771   2747 --:--:-- --:--:-- --:--:--
> 3052
> {
> "error": {
> "code": 401,
> "message": "The request you have made requires authentication.",
> "title": "Not Authorized"
> }
> }
>
> Regards,
> Ahmed.
>
>
>  --
>  *From:* Dolph Mathews [dolph.math...@gmail.com  'cvml', 'dolph.math...@gmail.com');>]
> *Sent:* Tuesday, October 02, 2012 12:12 PM
> *To:* Ahmed Al-Mehdi
> *Cc:* heckj; openstack@lists.launchpad.net  'openstack@lists.launchpad.net');>
> *Subject:* Re: [Openstack] Enabling logging in keystone.
>
>  You're missing a "5" on the admin_token you've specified on the command
> line.
>
>  012345SECRET99TOKEN01234 (your CLI arg)
> 012345SECRET99TOKEN012345 (keystone.conf)
>
>  -Dolph
>
>
> On Tue, Oct 2, 2012 at 1:08 PM, Ahmed Al-Mehdi  wrote:
>
> Hi Joe,
>
> I have put the conf file (renamed to ahmed_keystone.conf)  into gist.
>
> git://gist.github.com/3821846.git
>
> Please let me know if you have any issues accessing the file.
>
> Thank you very much for helping me out.  I have a feeling the issue might
> be in the python script to populate keystone. When I previously input the
> data manually, I got keystone configured properly.
>
> Regards,
> Ahmed.
>
>
> 
> From: heckj [he...@mac.com]
>  Sent: Tuesday, October 02, 2012 10:56 AM
>  To: Ahmed Al-Mehdi
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Enabling logging in keystone.
>
> Ahmed - can you put your keystone.conf into a paste or gist and share it
> with me? I'd be happy to help you debug this.
>
> I'm assuming you're running keystone on the system with the IP address
> 10.0.2.15, correct?
>
> -joe
>
> On Oct 2, 2012, at 10:45 AM, Ahmed Al-Mehdi  wrote:
>
> > Hi Joe,
> >
> > I noticed I did not put the port number in the URL, now I am getting a
> more meaningful error:
> >
> > #> keystone --token 012345SECRET99TOKEN01234 --endpoint
> http://10.0.2.15:35357/v2.0  tenant-list
> > No handlers could be found for logger "keystoneclient.client"
> > Unable to authorize user
> >
> > Regards,
> > Ahmed.
> >
> > 
> > From: 
> > openstack-bounces+ahmed=coraid@lists.launchpad.net[openstack-bounces+ahmed
> =coraid@lists.launchpad.net] On Behalf Of Ahmed Al-Mehdi [
> ah...@coraid.com]
> >

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

You're missing a "5" on the admin_token you've specified on the command
line.

012345SECRET99TOKEN01234 (your CLI arg)
012345SECRET99TOKEN012345 (keystone.conf)

-Dolph


On Tue, Oct 2, 2012 at 1:08 PM, Ahmed Al-Mehdi  wrote:

> Hi Joe,
>
> I have put the conf file (renamed to ahmed_keystone.conf)  into gist.
>
> git://gist.github.com/3821846.git
>
> Please let me know if you have any issues accessing the file.
>
> Thank you very much for helping me out.  I have a feeling the issue might
> be in the python script to populate keystone. When I previously input the
> data manually, I got keystone configured properly.
>
> Regards,
> Ahmed.
>
>
> 
> From: heckj [he...@mac.com]
> Sent: Tuesday, October 02, 2012 10:56 AM
> To: Ahmed Al-Mehdi
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Enabling logging in keystone.
>
> Ahmed - can you put your keystone.conf into a paste or gist and share it
> with me? I'd be happy to help you debug this.
>
> I'm assuming you're running keystone on the system with the IP address
> 10.0.2.15, correct?
>
> -joe
>
> On Oct 2, 2012, at 10:45 AM, Ahmed Al-Mehdi  wrote:
>
> > Hi Joe,
> >
> > I noticed I did not put the port number in the URL, now I am getting a
> more meaningful error:
> >
> > #> keystone --token 012345SECRET99TOKEN01234 --endpoint
> http://10.0.2.15:35357/v2.0  tenant-list
> > No handlers could be found for logger "keystoneclient.client"
> > Unable to authorize user
> >
> > Regards,
> > Ahmed.
> >
> > 
> > From: 
> > openstack-bounces+ahmed=coraid@lists.launchpad.net[openstack-bounces+ahmed=
> coraid@lists.launchpad.net] On Behalf Of Ahmed Al-Mehdi [
> ah...@coraid.com]
> > Sent: Tuesday, October 02, 2012 10:30 AM
> > To: heckj
> > Cc: openstack@lists.launchpad.net
> > Subject: Re: [Openstack] Enabling logging in keystone.
> >
> > Hi Joe,
> >
> > Unfortunately before I read your response I re-installed my Ubuntu
> server.  I repeated the same steps mentioned in the OpenStack document
> "Deploy and Install OpenStack - RedHat Ubuntu" and also used the script
> mentioned in it  (
> https://github.com/nimbis/keystone-init/blob/master/keystone-init.py) to
> populate keystone.  I reboot the server prior to running your suggested
> command and now running into a different issue, which I feel maybe due to
> not starting some service.  Btw, my host OS is Ubuntu 12.04 (32 bit)
> running inVirtualBox.
> >
> > Currently I am getting the following error:
> >
> > #> keystone --token 012345SECRET99TOKEN01234 --endpoint
> http://10.0.2.15/v2.0 tenant-list
> > No handlers could be found for logger "keystoneclient.client"
> > Unable to communicate with identity service: [Errno 111] Connection
> refused. (HTTP 400)
> >
> > How can I address the "logger" error.  I don't see any output sent to
> /var/log/keystone/keystone.log.
> >
> > I checked mysql and keystone is running:
> >
> > #> service keystone status
> > keystone start/running, process 741
> > #> ps aux | grep key
> > keystone   741  0.0  0.0   3028  1184 ?Ss   09:41   0:00 su -s
> /bin/sh -c exec keystone-all keystone
> > keystone   760  0.1  1.0  30872 21696 ?S09:41   0:01
> /usr/bin/python /usr/bin/keystone-all
> > root  1726  0.0  0.0   4388   828 tty1 S+   09:56   0:00 grep
> --color=auto key
> >
> > Thank you,
> > Ahmed.
> >
> >
> > 
> > From: heckj [he...@mac.com]
> > Sent: Monday, October 01, 2012 5:47 PM
> > To: Ahmed Al-Mehdi
> > Cc: openstack@lists.launchpad.net
> > Subject: Re: [Openstack] Enabling logging in keystone.
> >
> > Can you invoke the keystone commands with --token and --endpoint? That's
> the same thing as what you're trying to do with curl, but using the CLI to
> do the hard work of making sure you get the header's all nailed down
> correctly.
> >
> > Some good ones to try are:
> > (using your example "token" and "endpoint" from below - modify if they
> don't match your config)
> >
> >keystone --token ahmedadmintoken --endpoint
> http://10.176.20.158:35357/v2.0 tenant-list
> >keystone --token ahmedadmintoken --endpoint
> http://10.176.20.158:35357/v2.0 user-list
> >keystone --token ahmedadmintoken --endpoint
> http://10.176.20.158:35357/v2.0 service-list
> >keystone --token ahmedadmintoken --endpoint
> http://10.176.20.158:35357/v2.0 role-list
> >
> > All of these should report back *without* errors, even if you haven't
> bootstrapped Keystone to include any services, tenants, users, or roles.
> >
> > You can also add "--debug" (as in keystone --debug --token
> ahmedadmintoken --endpoint http://10.176.20.158:35357/v2.0 user-list) to
> see the underlying HTTP protocol going back and forth and what's getting
> sent to Keystone.
> >
> > -joe
> >
> > On Oct 1, 2012, at 5:30 PM, Ahmed Al-Mehdi  wrote:
> >> Actually, the curl command with the "X_Auth_Token" is my weak attempt
> to try to find a solution.  I am

Re: [Openstack] Enabling logging in keystone.

[Dolph Mathews]

The X-Auth-Token is what you get back from the authentication call you're
trying to make -- try removing the header completely. If you're still
getting a 401 error back, either your username or password is wrong, your
tenant name is wrong, or you haven't granted "adminUser" any role(s) on
"adminTenant".

-Dolph


On Mon, Oct 1, 2012 at 7:30 PM, Ahmed Al-Mehdi  wrote:

> Hi Joe,
>
> Actually, the curl command with the "X_Auth_Token" is my weak attempt to
> try to find a solution.  I am actually issuing the following command (per
> recommendation from the OpenStack document - "Install and Deploy Manual –
> Red Hat Ubuntu"):
>
> root@bodega:~# curl -d '{"auth": {"tenantName": "adminTenant",
> "passwordCredentials": {"username": "adminUser", "password":
> "secretword"}}}' -H "Content-type: application/json" -H "X_Auth_Token:
> ahmedadmintoken" http://10.176.20.158:35357/v2.0/tokens | python
> -mjson.tool
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100   2310   116  100   115  12927  12816 --:--:-- --:--:-- --:--:--
> 14500
> {
> "error": {
> "code": 401,
> "message": "The request you have made requires authentication.",
> "title": "Not Authorized"
> }
> }
>
> Regards,
> Ahmed.
>
>
> From: heckj 
> Date: Monday, October 1, 2012 5:23 PM
> To: Ahmed Al-Mehdi 
> Cc: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] Enabling logging in keystone.
>
> Ahmed -
>
> The header that's supposed to have the token within it is labelled
> "X-Auth-Token', not "X_Auth_Token".  Unless you're really comfortable with
> the protocol, I'd recommend using the keystone CLI from the
> python-keystoneclient to do your verifying, using it's debugging (which is
> to show you the curl output that you did below).
>
> -joe
>
> On Oct 1, 2012, at 5:12 PM, Ahmed Al-Mehdi  wrote:
>
> Hello,
>
> I am trying to verify the installation of keystone.  When I try to run
> some "curl" commands, I get the following error message:
>
> root@bodega:~/ahmed/keystone-init# curl -d '{"auth": {"tenantName":
> "adminTenant", "passwordCredentials": {"username": "adminUser", "password":
> "secretword"}}}' -H "Content-type: application/json" -H "X_Auth_Token:
> ahmedadmintoken" http://10.176.20.158:35357/v2.0/tokens | python
> -mjson.tool
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100   2310   116  100   115  15205  15074 --:--:-- --:--:-- --:--:--
> 16571
> {
> "error": {
> "code": 401,
> "message": "The request you have made requires authentication.",
> "title": "Not Authorized"
> }
> }
>
>
> I don't see any message in the /var/log/keystone/logging.conf file.   I
> can pass "-debug" option to keystone to enable debugging, but I am not sure
> how to do that from curl.  Following is content of
> /etc/keystone/logging.conf file:
>
> root@bodega:~# cat /etc/keystone/logging.conf
> [loggers]
> keys=root
>
> [formatters]
> keys=normal,normal_with_name,debug
>
> [handlers]
> keys=production,file,devel
>
> [logger_root]
> level=WARNING
> handlers=file
>
> [handler_production]
> class=handlers.SysLogHandler
> level=ERROR
> formatter=normal_with_name
> args=(('localhost', handlers.SYSLOG_UDP_PORT),
> handlers.SysLogHandler.LOG_USER)
>
> [handler_file]
> class=FileHandler
> level=DEBUG
> formatter=normal_with_name
> args=('/var/log/keystone/keystone.log', 'a')
>
> [handler_devel]
> class=StreamHandler
> level=NOTSET
> formatter=debug
> args=(sys.stdout,)
>
> [formatter_normal]
> format=%(asctime)s %(levelname)s %(message)s
>
> [formatter_normal_with_name]
> format=(%(name)s): %(asctime)s %(levelname)s %(message)s
>
> [formatter_debug]
> format=(%(name)s): %(asctime)s %(levelname)s %(module)s %(funcName)s
> %(message)s
> root@bodega:~#
>
> Any help would be greatly appreciated.
>
> Regards,
> Ahmed.
>
>
>
> ___
> 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

Re: [Openstack] HTTP_X_SERVICE_CATALOG endpoints_links

[Dolph Mathews]

The environment variables that auth_token sets are documented in the
module's docstring:
https://github.com/openstack/keystone/blob/master/keystone/middleware/auth_token.py

As these variables are the defined interface for any projects consuming
authentication services from middleware, it's safe to say they'll be
supported be supported by any variations of auth_token, and will either
continue to be supported or carefully deprecated.

Speaking of, there are currently three headers that were deprecated prior
to the release of essex (i.e. they were documented as deprecated in both
essex and folsom), and could be reviewed for removal in grizzly
(HTTP_X_USER, HTTP_X_ROLE, HTTP_X_TENANT).

-Dolph


On Mon, Oct 1, 2012 at 2:56 PM, Tong Li  wrote:

> After a user gets authenticated, each following request will have a header
> named HTTP_X_SERVICE_CATALOG which contains service end point links, can
> any one tell me if it is safe to use the information contained in the
> header to get the various end points from a filter in the pipeline? Notice
> this header is set in the keystone, any other implementation of keystone
> may choose not to include the information in the header, can anyone tell me
> putting the endpoints in the headers is required by any implementation like
> keystone for authentication?
>
> Thanks.
>
> Tong Li
> Emerging Technologies & Standards
> Building 501/B205
> liton...@us.ibm.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

Re: [Openstack] keystone user-role-list error

[Dolph Mathews]

By default, I believe it shows you your own roles. With a token/endpoint
specified (bypassing auth), it should work if you specify a user & tenant:

$ keystone help user-role-list
usage: keystone user-role-list [--user-id ] [--tenant-id
]

List roles granted to a user

Optional arguments:
  --user-idList roles granted to a user
  --tenant-id 
List roles granted on a tenant

-Dolph


On Sat, Sep 29, 2012 at 2:54 PM, heckj  wrote:

> Hey Asher,
>
> That's a bug in keystoneclient - the method for doing the role listing is
> making a bad assumption that you're authenticating with a username and
> password, not handing in a token, and is getting wrapped around the axle
> trying to figure out what tenant you are. If you create an admin account
> with the --token and --endpoint options, and then use those options for
> this same command, you should be OK.
>
> This should definitely be filed as a bug :-)
> https://bugs.launchpad.net/python-keystoneclient/+bug/1058750
>
> Use that link to subscribe to the bug if you want to track it's progress.
>
> -joe
>
> On Sep 29, 2012, at 5:35 AM, Asher Newcomer  wrote:
>
> It looks like user-role-list is a recently added command in keystone (
> launchpad ).
>
> When I run it on a new keystone install in Ubuntu 12.04 I get:
>
> keystone --token  --endpoint 
> http://192.168.1.11:35357/v2.0user-role-list
>
> 'Client' object has no attribute 'auth_tenant_id'
>
> It looks client side, and no corresponding entry in keystone.log. Bug?
>
> Thanks,
>
> Asher
> ___
> 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

Re: [Openstack] keystone install / user-role-list error

[Dolph Mathews]

As you're definitely not the first person to run into this problem, I've
opened a bug so that we can improve the error feedback in this scenario:

https://bugs.launchpad.net/keystone/+bug/1058494

-Dolph


On Sat, Sep 29, 2012 at 1:51 AM, Dolph Mathews wrote:

> It looks like at least one of your endpoints isn't being parsed correctly.
>
> List your endpoints:
>
> keystone --token  --endpoint http://192.168.1.11:35357/v2.0
>  endpoint-list
>
> ... and make sure they all appear as expected (at least one public URL is
> wrong, according to the stack trace). Feel free to paste your endpoint list
> back on the mailing list if you have any trouble.
>
> -Dolph
>
>
> On Sat, Sep 29, 2012 at 12:06 AM, Asher Newcomer wrote:
>
>> Hi,
>>
>> I'm sure I've made a simple error, but I'm momentarily stuck trying to
>> work through a Folsom install on a fresh Ubuntu 12.04 box.  I've stepped
>> through the process for installing the identity service described here:
>> doc<http://docs.openstack.org/trunk/openstack-compute/install/apt/content/ch_installing-openstack-identity-service.html>
>> .
>>
>> Everything seemed smooth until the end, when I tried to validate the
>> install with the curl command provided:
>>
>> curl -d '{"auth": {"tenantName": "myTenant",
>> "passwordCredentials":{"username": "adminUser", "password":
>> "myPassword"}}}' -H "Content-type: application/json"
>> http://192.168.1.11:35357/v2.0/tokens | python -mjson.tool
>>
>> Which gave a error 500: tenant, and a corresponding entry in keystone.log
>> of:
>>
>> (root): 2012-09-28 23:45:50,651 ERROR u'tenant'
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line
>> 204, in __call__
>> result = method(context, **params)
>>   File "/usr/lib/python2.7/dist-packages/keystone/service.py", line 336,
>> in authenticate
>> metadata=metadata_ref)
>>   File "/usr/lib/python2.7/dist-packages/keystone/catalog/core.py", line
>> 78, in get_catalog
>> return self.driver.get_catalog(user_id, tenant_id, metadata)
>>   File
>> "/usr/lib/python2.7/dist-packages/keystone/catalog/backends/sql.py", line
>> 162, in get_catalog
>> catalog[region][srv_type]['publicURL'] = public_url % d
>> KeyError: u'tenant'
>>
>> So I decided to poke around a bit and tried:
>>
>> keystone --token  --endpoint 
>> http://192.168.1.11:35357/v2.0user-role-list
>>
>> and get
>>
>> 'Client' object has no attribute 'auth_tenant_id'
>>
>> Any idea what I've done wrong?
>>
>> Thanks in advance.
>>
>> ___
>> 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

Re: [Openstack] keystone install / user-role-list error

[Dolph Mathews]

It looks like at least one of your endpoints isn't being parsed correctly.

List your endpoints:

keystone --token  --endpoint http://192.168.1.11:35357/v2.0
 endpoint-list

... and make sure they all appear as expected (at least one public URL is
wrong, according to the stack trace). Feel free to paste your endpoint list
back on the mailing list if you have any trouble.

-Dolph


On Sat, Sep 29, 2012 at 12:06 AM, Asher Newcomer  wrote:

> Hi,
>
> I'm sure I've made a simple error, but I'm momentarily stuck trying to
> work through a Folsom install on a fresh Ubuntu 12.04 box.  I've stepped
> through the process for installing the identity service described here:
> doc
> .
>
> Everything seemed smooth until the end, when I tried to validate the
> install with the curl command provided:
>
> curl -d '{"auth": {"tenantName": "myTenant",
> "passwordCredentials":{"username": "adminUser", "password":
> "myPassword"}}}' -H "Content-type: application/json"
> http://192.168.1.11:35357/v2.0/tokens | python -mjson.tool
>
> Which gave a error 500: tenant, and a corresponding entry in keystone.log
> of:
>
> (root): 2012-09-28 23:45:50,651 ERROR u'tenant'
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line
> 204, in __call__
> result = method(context, **params)
>   File "/usr/lib/python2.7/dist-packages/keystone/service.py", line 336,
> in authenticate
> metadata=metadata_ref)
>   File "/usr/lib/python2.7/dist-packages/keystone/catalog/core.py", line
> 78, in get_catalog
> return self.driver.get_catalog(user_id, tenant_id, metadata)
>   File
> "/usr/lib/python2.7/dist-packages/keystone/catalog/backends/sql.py", line
> 162, in get_catalog
> catalog[region][srv_type]['publicURL'] = public_url % d
> KeyError: u'tenant'
>
> So I decided to poke around a bit and tried:
>
> keystone --token  --endpoint 
> http://192.168.1.11:35357/v2.0user-role-list
>
> and get
>
> 'Client' object has no attribute 'auth_tenant_id'
>
> Any idea what I've done wrong?
>
> Thanks in advance.
>
> ___
> 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

Re: [Openstack] Keystone: Get user/tenant by name returning full list

[Dolph Mathews]

I'm not aware that this was ever implemented during essex (it was available
in diablo) -- definitely worth opening a bug!

-Dolph


On Fri, Sep 21, 2012 at 11:15 AM, boden  wrote:

> As per the Keystone v2.0 API docs, I've been trying to use the 'get user
> by name' and 'get tenant by name' APIs to retrieve the respective
> resource by name. The URI signatures are:
>
> v2.0/users​?name=string
> v2.0/tenants​?name=string
>
> respectively.
>
> However, both of these APIs are returning the full list (collection) of
> users/tenants rather than the single resource specified in the 'name'
> parameter.
>
> EX:
> 
> (request)
> GET http://localhost:35357/v2.0/tenants?name=DefaultTenant
>
> (response)
> {u'tenants': [{u'id': u'0e98e4ac9590428c997e3aabf18a49d4', u'enabled':
> True, u'description': u'Services Tenant', u'name': u'Services'}, {u'id':
> u'6f8945f2d47f4abea149b7a0176b12a8', u'enabled': True, u'description':
> u'Default Tenant', u'name': u'DefaultTenant'}], u'tenants_links': []}
> 
>
> I did a bug search but didn't see anything existing. Hence I'm trying to
> confirm this issue is worthy of a defect?
>
> Thx
>
>
> ___
> 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

Re: [Openstack] Keystone v2.0 dev API doc confusion

[Dolph Mathews]

I'm not sure what's wrong here, but I definitely want to make sure this is
fixed-- just assigned the bug to myself.

-Dolph


On Fri, Sep 21, 2012 at 8:43 AM, Anne Gentle  wrote:

> Hi Boden -
> This is a known bug with the way those Keystone dev docs are output.
> I'm tracking it here:
> https://bugs.launchpad.net/openstack-manuals/+bug/1015119
>
> I can help someone fix this - thanks for pointing it out again. Please
> vote on that bug to raise its visibility to get it attention.
>
> Thanks,
> Anne
>
> On Fri, Sep 21, 2012 at 3:53 AM, boden  wrote:
> > I came across the following Keystone dev API docs:
> >
> http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_listRolesForUserOnTenant_v2.0_tenants__tenantId__users__user_id__roles_Admin_API_Service_Developer_Operations-d1e1356.html
> > This set of keystone v2.0 docs includes documented APIs for operations
> > such as 'List Roles for User on Tenant', 'Check Token', etc.. I tried a
> > few of these APIs on some recent code from master -- works as documented.
> >
> > However if I follow the typical API doc links: www.openstack.org >
> > Documentation > API Documentation > OpenStack Identity Service Developer
> > Guide API 2.0, I end up at the following location:
> > http://docs.openstack.org/api/openstack-identity-service/2.0/content/
> > This page does not contain a number of the documented APIs from the 1st
> > link I posted. For example no info on 'List Roles for User on Tenant',
> > 'Check Token', etc..
> >
> > Can someone help me understand which version of the documented APIs are
> > current (supported) for Folsom? I'm thinking maybe the 1st doc link I
> > posted is being created for folsom, but is not yet "live".
> >
> > Thanks much
> >
> >
> > ___
> > 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

Re: [Openstack] [OSSA 2012-014] Revoking a role does not affect existing tokens (CVE-2012-4413)

[Dolph Mathews]

Ryan Lane deserves recognition for originally identifying this as a
potential vulnerability.

Thanks, Ryan!

-Dolph


On Wed, Sep 12, 2012 at 11:36 AM, Thierry Carrez wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> OpenStack Security Advisory: 2012-014
> CVE: CVE-2012-4413
> Date: September 12, 2012
> Title: Revoking a role does not affect existing tokens
> Impact: High
> Reporter: Dolph Mathews (Rackspace)
> Products: Keystone
> Affects: Essex, Folsom
>
> Description:
> Dolph Mathews reported a vulnerability in Keystone. Granting and
> revoking roles from a user is not reflected upon token validation for
> pre-existing tokens. Pre-existing tokens continue to be valid for the
> original set of roles for the remainder of the token's lifespan, or
> until explicitly invalidated. This fix invalidates all tokens held by
> a user upon role grant/revoke to circumvent the issue.
>
> Folsom fix:
>
> http://github.com/openstack/keystone/commit/efb6b3fca0ba0ad768b3e803a324043095d326e2
>
> Essex fix:
>
> http://github.com/openstack/keystone/commit/58ac6691a21675be9e2ffb0f84a05fc3cd4d2e2e
>
> References:
> https://bugs.launchpad.net/keystone/+bug/1041396
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-4413
>
> Notes:
> This fix will be included in the future Keystone 2012.1.3 stable
> update and the upcoming Folsom-RC1 development milestone.
>
> - --
> Thierry Carrez (ttx)
> OpenStack Vulnerability Management Team
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJQULoUAAoJEFB6+JAlsQQjGacQAJUvJb+oIjh73KAYYuDpl/YP
> PqJa4nmjVin7CyQ8AbxHK63xrAQ7isPFpCCqtEmjZ5kvFCrJRHiQggHNqISRhnvo
> +HyS6RSn4Vrp001PSZSmQI5MpgkeWhbOy+fk4/ZY7hFgUyS2YqC8YiK7DTMdKRBi
> toWOHRVWrmA4fUEDDcDdm9XzRseTC0cZAbj9bYAF+vXPdpxeGpq5l9Kb6yDezXGD
> 62dFvHghVTWdUIN+gK4V4d77PoyeO9NRd4Ud0GjDpV/asQL31dW6B4aRPYVDPhL3
> 7xcnhRsnZ3Y5J31n+7E/gMF+J+6kOaY/DNFZQ8chNW18kplYnmJnm7s3BJNjD512
> UF/S5A5sH1Rk/vwe2nAHSqvQ1Dq3K0sRvW3YCijG2Rdj3mhBOr6OlvT5uJmnkeJT
> GQQ8SR3y+ZLS/2EEW+cVjDMxV4Gnf9Zzrw/tSjVp6QLmJAkG8qrFmgdisQ/Jao4M
> ygE8ZVu8lJq7N8b+k8XkB+bhz9E9V6hYOUuGoifEHRIPki/Ed7++BcdVTQdQYpAL
> kDTaoVZt1+plwAu4ZBLxUg1vhVz19qgDc7UeoY1sPc1JcRWp/ONnp6K4z+Y+7Rsx
> 3E4FLH0/qgFxKDHdGX91Plehk9dIEjHcGtKaXI8vOvGT17srYQaF6Y7rc+9TwaqI
> bggBCxcI2PLQgjuWyF4M
> =+6UN
> -END PGP SIGNATURE-
>
> ___
> 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