Ask Your Question

rshoemaker's profile - activity

2017-09-20 21:48:42 -0500 received badge  Famous Question (source)
2016-05-09 07:01:33 -0500 received badge  Popular Question (source)
2016-05-09 07:01:33 -0500 received badge  Notable Question (source)
2016-04-07 15:02:07 -0500 asked a question keystone Identity Admin API v2.0 behavior RHEL OS -vs- Community OS

Hi,

I've noticed there's a difference between the way the RHEL OS and Community OS identity admin apis work and I'm hoping someone can provide a little perspective on what I'm seeing. Specifically, it looks like this API is expecting different values for {user-id} on different releases of OS:

/v2.0/tenants/{tenant-id}/users/{user-id}/roles

We are currently testing our product on Community Icehouse/Juno/Kilo as well as RHEL Kilo.

On Community Icehouse/Juno/Kilo, we are passing a user name for {user-id}:

$ curl -H "X-Auth-Token:$ostoken" http://keystone.somedomain.com:35357/v2.0/tenants/02b3cc5d8e0b420e8a15777f9a7d6420/users/rshoemaker/roles
{"roles": [{"id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}]}

If we pass a user id, then we get a 404:

$ curl -H "X-Auth-Token:$ostoken" http://keystone.somedomain.com:35357/v2.0/tenants/02b3cc5d8e0b420e8a15777f9a7d6420/users/9fe2ff9ee4384b1894a90878d3e92bab/roles
{"error": {"message": "Could not find user: 9fe2ff9ee4384b1894a90878d3e92bab", "code": 404, "title": "Not Found"}}

On RHEL Kilo, if we pass the user name in, we get a 404:

$ curl -H "X-Auth-Token:$ostoken" http://rh-openstack.somedomain.com:35357/v2.0/tenants/1f6807689c904d6f9824fa3d202f5743/users/rshoemaker/roles
{"error": {"message": "Could not find user: rshoemaker", "code": 404, "title": "Not Found"}}

But if we pass the user id it works fine:

$ curl -H "X-Auth-Token:$ostoken" http://rh-openstack.somedomain.com:35357/v2.0/tenants/1f6807689c904d6f9824fa3d202f5743/users/3cf1b596585e419dac0c3bb94fd2f3b5/roles
{"roles": [{"id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}]}

So, to summarize:

  • RHEL Kilo expects user ids and fails on user names
  • Community Icehouse/Juno/Kilo expect user names and fails on user ids

Can anyone explain why there's a difference? I'd almost feel better if Community Kilo and RHEL Kilo worked the same, but perhaps this is a case when RH changed the code to accept a user-id instead.

Based on the http://developer.openstack.org/api-ref-identity-admin-v2.html (OS docs here), it certainly seems like the API was meant to take a user-id, not a user-name.

2015-10-08 16:48:00 -0500 received badge  Famous Question (source)
2015-09-23 05:27:09 -0500 received badge  Notable Question (source)
2015-09-21 09:54:24 -0500 received badge  Popular Question (source)
2015-09-17 21:06:30 -0500 asked a question cloud-init metadata failure on Kilo

Hi,

I've built a CentOS 6 image following the OS instructions (docs.openstack.org/image-guide/content/centos-image.html) and uploaded it to our Icehouse, Juno, and Kilo installations (RDO packstack --allinone).

I can launch instances of the image fine on Icehouse and Juno - cloud-init runs properly, my ssh key is injected and I can access the instance no problem. When I try to launch an instance of the image on Kilo, I see the following errors:

Starting cloud-init: Cloud-init v. 0.7.5 running 'init-local' at Wed, 16 Sep 2015 17:33:57 +0000. Up 23.67 seconds.
Starting cloud-init: Cloud-init v. 0.7.5 running 'init' at Wed, 16 Sep 2015 17:33:58 +0000. Up 24.38 seconds.
ci-info: ++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++
ci-info: +--------+------+--------------+---------------+-------------------+
ci-info: | Device |  Up  |   Address    |      Mask     |     Hw-Address    |
ci-info: +--------+------+--------------+---------------+-------------------+
ci-info: |   lo   | True |  127.0.0.1   |   255.0.0.0   |         .         |
ci-info: |  eth0  | True | 192.168.1.17 | 255.255.255.0 | fa:16:3e:c3:27:b8 |
ci-info: +--------+------+--------------+---------------+-------------------+
ci-info: +++++++++++++++++++++++++++++++Route info++++++++++++++++++++++++++++++++
ci-info: +-------+-------------+-------------+---------------+-----------+-------+
ci-info: | Route | Destination |   Gateway   |    Genmask    | Interface | Flags |
ci-info: +-------+-------------+-------------+---------------+-----------+-------+
ci-info: |   0   | 192.168.1.0 |   0.0.0.0   | 255.255.255.0 |    eth0   |   U   |
ci-info: |   1   |   0.0.0.0   | 192.168.1.1 |    0.0.0.0    |    eth0   |   UG  |
ci-info: +-------+-------------+-------------+---------------+-----------+-------+
2015-09-16 13:34:13,246 - util.py[WARNING]: Getting data from <class 'cloudinit.sources.DataSourceOpenStack.DataSourceOpenStack'> failed
2015-09-16 13:34:27,589 - util.py[WARNING]: Failed fetching userdata from url http://169.254.169.254/2009-04-04/user-data
2015-09-16 13:34:36,662 - util.py[WARNING]: Failed fetching metadata from url http://169.254.169.254/2009-04-04/meta-data
Starting cloud-init: Cloud-init v. 0.7.5 running 'modules:config' at Wed, 16 Sep 2015 17:34:37 +0000. Up 62.71 seconds.
Starting cloud-init: Cloud-init v. 0.7.5 running 'modules:final' at Wed, 16 Sep 2015 17:34:37 +0000. Up 63.27 seconds.
Cloud-init v. 0.7.5 finished at Wed, 16 Sep 2015 17:34:37 +0000. Datasource DataSourceNone.  Up 63.40 seconds
2015-09-16 13:34:37,905 - cc_final_message.py[WARNING]: Used fallback datasource

I configured the image to allow root to ssh in via password so I can gain access to the node. What I see is that I can manually grab the meta data no problem:

# curl http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
latest

# curl http://169.254.169.254/latest/meta-data
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
instance-action
instance-id
instance-type
kernel-id
local-hostname
local-ipv4
placement/
public-hostname
public-ipv4
public-keys/
ramdisk-id
reservation-id
security-groups

But if I attempt to restart the cloud-init service, it often fails with similar errors:

# service cloud-init restart
Starting cloud-init: Cloud-init v. 0.7.5 running 'init' at Thu, 17 Sep
2015 10:36:49 +0000. Up 61395.45 seconds.
ci-info: [....SNIP....]
2015-09-17 06:37:11,295 - util.py[WARNING]: Failed fetching metadata from url http://169.254.169.254/latest/meta-data

The nova-api.log shows the following error:

2015-09-17 06:46:45.485 5065 INFO nova.api.ec2 [-] 0.529s ...
(more)