User/AccessKey/WaitConditionHandle don't work on devstack

Actually, this may be a result of my recent changes to user.py:

  File "/opt/stack/heat/heat/engine/resources/user.py", line 141, in FnGetAtt
    res = self._secret_accesskey()
  File "/opt/stack/heat/heat/engine/resources/user.py", line 113, in _secret_accesskey
    user_id = self.keystone().get_user_by_name(self.properties['UserName'])
  File "/opt/stack/heat/heat/common/heat_keystoneclient.py", line 93, in get_user_by_name
    users = self.client.users.list(tenant_id=self.context.tenant_id)
  File "/opt/stack/python-keystoneclient/keystoneclient/v2_0/users.py", line 125, in list
    "users")
  File "/opt/stack/python-keystoneclient/keystoneclient/base.py", line 67, in _list
    resp, body = self.api.get(url)

It should be possible to call FnGetAtt to get the secret access key for the user *in the request context* without needing any special admin role - previously I avoided client.users.list but I seem to have introduced a regression here by calling get_user_by_name in FnGetAtt

I had assumed that only users with the admin flag could create new users, which the demo user doesn't have. I hadn't looked deeply into it though.

Yeah, so there are really two problems:
- The user creating the stack needs to have the admin role if they want to use these resources (not sure if this is actually a problem, or if we just need to document the addition of the demo user to the right role in the Devstack getting started, although the Fedora getting started procedure results in a user which already has the admin role)

- The AccessKey resource FnGetAtt call to _secret_accesskey() must work *without* the admin role, because cfn-hup uses the in-instance user credentials, which we definitely don't want to have the admin role. This then allows the in-instance user credentials to read the instance resource metadata (via a DescribeStackResource call to the CFN api), which includes the secret key _for the in-instance user_ which will allow us to implement stuff like in-instance key expiry/rotation (like AWS does for IAM Roles) if we wish.

So the first problem is either a patch to devstack or a change to the docs I think (SteveB - do you have any strong opinions on which?)

The second problem is a regression caused by my user.py rework last week - I have a fix for this which I'm currently testing

Fix proposed to branch: master
Review: https://review.openstack.org/17353

Reviewed: https://review.openstack.org/17353
Committed: http://github.com/openstack/heat/commit/960a76ba4464423440c9f497bb1126b88fbd1ca8
Submitter: Jenkins
Branch: master

commit 960a76ba4464423440c9f497bb1126b88fbd1ca8
Author: Steven Hardy <email address hidden>
Date: Mon Dec 3 11:04:12 2012 +0000

    heat engine : Rework AccessKey to avoid keystone user lookup

    Rework the mapping if AccessKey UserName property to keystone
    user_id - the recent refactor reintroduces a keystone.user.list
    call, which requires admin role, which we want to avoid or the
    in-instance user can't request their own secret key via cfn-hup

    ref bug 1085049

    Change-Id: I456dff67f56336a9052180dc3c59cea8b7a173bd
    Signed-off-by: Steven Hardy <email address hidden>