Bug 1076611

Summer,

I have cloned this request for a documentation change for the orchestration config for RHOS 5.0.  Hopefully I picked the correct documentation component.  If you need further information, feel free to needinfo on shardy, who can provide appropriate information.

Regards
-steve

This bug is being assigned to Don Domingo, who is now the designated docs specialist for Heat.

For RHOS5 I'm thinking this should be added to the Installation and Configuration Guide. Changing the component accordingly.

Hi Steve (Hardy),

Seeing as we're not sure if python-openstackclient is making it to Icehouse, it looks like we'll just be sticking to using the script in https://review.openstack.org/#/c/78048/ for the "create a keystone domain for heat" step.

Speaking of which, where would users find this script (absolute path)? Also, is there a specific package that provides it? The Orchestration service is made up of several packages.

(In reply to Don Domingo from comment #5)
> Hi Steve (Hardy),
> 
> Seeing as we're not sure if python-openstackclient is making it to Icehouse,
> it looks like we'll just be sticking to using the script in
> https://review.openstack.org/#/c/78048/ for the "create a keystone domain
> for heat" step.

Oh, that is unfortunate :(  What are the barriers to shipping python-openstackclient in RHOS 5.0?

IMHO it is essential, since it's the only CLI interface to v3 keystone functionality, hence customers are highly likely to need it to interact with services making use of keystone v3 features (such as domains).
 
> Speaking of which, where would users find this script (absolute path)? Also,
> is there a specific package that provides it? The Orchestration service is
> made up of several packages.

It's not currently packaged, and it was never designed to be a supportable (from a product perspective) solution.  It was intended to provide a short-term workaround for TripleO while they transitioned to python-openstackclient.

The problem with using this approach is that although it may be possible to configure heat initially, it will be impossible to debug any subsequent problems, because those providing support won't be able to request info re domains, or any keystone data which is not in the default domain without writing more special scripts.  

Therefore python-openstackclient (which has been chosen, rightly or wrongly by keystone upstream as the *only* interface to v3 keystone) is the only realistically supportable solution, IMO.

Bug raised to track getting python-openstackclient into RHOS 5.0:

https://bugzilla.redhat.com/show_bug.cgi?id=1087562

Hi Steven (Hardy), 

Sorry about that, I missed https://bugzilla.redhat.com/show_bug.cgi?id=1076172#c4. Please disregard my uncertainty about python-openstackclient. :-)

In any case, I could not find any instructions on how to actually use the client to create a HEAT domain. Can you help me out?

(In reply to Don Domingo from comment #8)
> In any case, I could not find any instructions on how to actually use the
> client to create a HEAT domain. Can you help me out?

Hi, 

There are details linked from the initial report:

These are the commits which added the options, and include python-openstack commands to create the domain/user:
https://review.openstack.org/#/c/73978/
https://review.openstack.org/#/c/76035/

These are the associated devstack changes (now merged):
https://review.openstack.org/#/c/73324/
https://review.openstack.org/#/c/75424/
https://review.openstack.org/#/c/76036/

Cut/pasting from the commit messages:

To create the domain:

"
The domain should be created via python-openstackclient (which is the only CLI interface to the v3keystone API, the keystoneclient shell is v2.0 only), e.g:

openstack --os-token <atoken> --os-url=http://<KS_IP>:5000/v3 \
    --os-identity-api-version=3 domain create heat
"

And to create the user:

"
the domain should be created via
python-openstackclient and heat.conf updated with the username and
password:

openstack --os-token <atoken> --os-url=http://<KS_IP>:5000/v3 \
    --os-identity-api-version=3 user create heat_domain_admin \
    --password <password> --domain <stack_user_domain id>

openstack --os-token <atoken> --os-url=http://<KS_IP>:5000/v3 \
    --os-identity-api-version=3 role add --user heat_domain_admin \
    --password <password> --domain <stack_user_domain id> \
    --domain <stack_user_domain id> admin
"

The domain ID, username and password should be updated in heat.conf like this:

[DEFAULT]
stack_domain_admin_password = password
stack_domain_admin = heat_domain_admin
stack_user_domain = <domain id returned from domain create above>

Once this is done, heat-engine can be (re)started and heat should create users/projects in the "heat" domain we just created, not the project/domain of the stack owner.

Here's a procedure to verify all is working (taken from my comments in https://bugs.launchpad.net/puppet-heat/+bug/1288880/comments/1)


1. Review heat.conf

[DEFAULT]
stack_domain_admin_password = apassword
stack_domain_admin = heat_domain_admin
stack_user_domain = 7e4f6598443b4f5e8ac3010728885329

These three entries should exist with values set appropriately in the DEFAULT section of the heat.conf

2. Ensure the heat domain and heat_domain_admin user exist in keystone:

-bash-4.2$ openstack --os-identity-api-version=3 --os-url=http://127.0.0.1:5000/v3 --os-token foobar domain list | grep heat
| 7e4f6598443b4f5e8ac3010728885329 | heat | True | Owns users and projects created by heat |

-bash-4.2$ openstack --os-identity-api-version=3 --os-url=http://127.0.0.1:5000/v3 --os-token foobar user list | grep heat| 50d363c7a1e245fbb337669e432eb87b | heat_domain_admin |
| 7357ce487a3e449bac41bc54aa756f52 | heat |

3. Ensure stack domain users can be created and deleted via a stack, and that they end up in the heat stack domain

-bash-4.2$ cat user_access2.yaml
heat_template_version: 2013-05-23

resources:
  user:
    type: AWS::IAM::User

  access:
    type: AWS::IAM::AccessKey
    properties:
      UserName: { get_resource : user }

-bash-4.2$ heat stack-create ua2 -f user_access2.yaml
+--------------------------------------+------------+--------------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+--------------------+----------------------+
| 769f96d4-6351-453f-b00c-7b06aa7b93ce | ua2 | CREATE_IN_PROGRESS | 2014-04-04T17:07:36Z |
+--------------------------------------+------------+--------------------+----------------------+

-bash-4.2$ openstack --os-identity-api-version=3 --os-url=http://127.0.0.1:5000/v3 --os-token foobar user list | grep ua2
| 53750398d9b1465e9e813b933fb45e2e | ua2-user-wf2s2eld3qnw |

-bash-4.2$ openstack --os-identity-api-version=3 --os-url=http://127.0.0.1:5000/v3 --os-token foobar user show 53750398d9b1465e9e813b933fb45e2e
+--------------------+-------------------------------------------------------------------------------+
| Field | Value |
+--------------------+-------------------------------------------------------------------------------+
| default_project_id | c45c5e533d7a40568493dee6b4048b99 |
| domain_id | 7e4f6598443b4f5e8ac3010728885329 |
| enabled | True |
| id | 53750398d9b1465e9e813b933fb45e2e |
| links | {u'self': u'http://localhost:5000/v3/users/53750398d9b1465e9e813b933fb45e2e'} |
| name | ua2-user-wf2s2eld3qnw |
+--------------------+-------------------------------------------------------------------------------+

-bash-4.2$ openstack --os-identity-api-version=3 --os-url=http://127.0.0.1:5000/v3 --os-token foobar domain show 7e4f6598443b4f5e8ac3010728885329
+-------------+---------------------------------------------------------------------------------+
| Field | Value |
+-------------+---------------------------------------------------------------------------------+
| description | Owns users and projects created by heat |
| enabled | True |
| id | 7e4f6598443b4f5e8ac3010728885329 |
| links | {u'self': u'http://localhost:5000/v3/domains/7e4f6598443b4f5e8ac3010728885329'} |
| name | heat |
+-------------+---------------------------------------------------------------------------------+

-bash-4.2$ openstack --os-identity-api-version=3 --os-url=http://127.0.0.1:5000/v3 --os-token foobar project show c45c5e533d7a40568493dee6b4048b99
+-------------+----------------------------------------------------------------------------------+
| Field | Value |
+-------------+----------------------------------------------------------------------------------+
| description | Heat stack user project |
| domain_id | 7e4f6598443b4f5e8ac3010728885329 |
| enabled | True |
| id | c45c5e533d7a40568493dee6b4048b99 |
| links | {u'self': u'http://localhost:5000/v3/projects/c45c5e533d7a40568493dee6b4048b99'} |
| name | 048aeaa4c2714d268d669521d314c304-769f96d4-6351-453f-b00c-7b06aa7 |
+-------------+----------------------------------------------------------------------------------+

Correction, using the code from devstack/lib/heat is better, the examples I pasted from the commit messages are not quite correct:

Create the domain:

openstack --os-token $OS_TOKEN --os-url=$KS_ENDPOINT_V3 --os-identity-api-version=3 domain create heat --description "Owns users and projects created by heat"

The domain ID is returned by this command, and is referred to as $HEAT_DOMAIN_ID below.

Create the user:

openstack --os-token $OS_TOKEN --os-url=$KS_ENDPOINT_V3 --os-identity-api-version=3 user create --password $PASSWORD --domain $HEAT_DOMAIN_ID heat_domain_admin --description "Manages users and projects created by heat"

The user ID is returned by this command and is referred to as $DOMAIN_ADMIN_ID below:

Make the user a domain admin:

openstack --os-token $OS_TOKEN --os-url=$KS_ENDPOINT_V3 --os-identity-api-version=3 role add --user $DOMAIN_ADMIN_ID --domain $HEAT_DOMAIN_ID admin