Bug 1076611 - documentation requires heat update for domain users
Summary: documentation requires heat update for domain users
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Installation_and_Configuration_Guide
Version: 5.0 (RHEL 7)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 5.0 (RHEL 7)
Assignee: Don Domingo
QA Contact: Andrew Dahms
URL:
Whiteboard: docs-rhos5-icg-others
Depends On: 1076172
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-14 16:08 UTC by Steven Dake
Modified: 2018-12-06 16:06 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1076172
Environment:
Last Closed: 2014-09-04 13:07:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Steven Dake 2014-03-14 16:08:11 UTC
+++ This bug was initially created as a clone of Bug #1076172 +++

Description of problem:
Some functionality has landed upstream for Icehouse which requires creating a domain, and a domain admin user, then setting details of both in the heat configuration file.

Heat will still work without these settings, but will still be affected by https://bugs.launchpad.net/heat/+bug/1089261

I've raised https://bugs.launchpad.net/puppet-heat/+bug/1288880 to track getting the required changes into the puppet manfifests used by packstack.

--- Additional comment from Steven Hardy on 2014-03-13 13:37:21 EDT ---

Cut/paste details from upstream puppet-heat bug.  Note new dependency on python-openstackclient.

--
Recent changes landed under the instance-users BP require some updates to the heat installation procedure, specifically:

1. Create a keystone domain and set the id in heat.conf (stack_user_domain)
2. Create a keystone user, and make them a domain admin (admin role in the domain created above)
3. Update heat.conf with the username and password of the domain-admin user (stack_domain_admin and stack_domain_admin_password)

This is the BP:
https://blueprints.launchpad.net/heat/+spec/instance-users

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/

Note this introduces a dependency on python-openstackclient, because the "keystone" CLI tool provided by python-keystoneclient is deprecated and does not support the v3 keystone API, ref this discussion:
http://lists.openstack.org/pipermail/openstack-dev/2014-January/025629.html

In the event python-openstackclient is not available, heat provides a helper script which can be used to create the domain/user, but it's probably preferable to use openstackclient like devstack if available:
https://review.openstack.org/#/c/78048/

--- Additional comment from RHEL Product and Program Management on 2014-03-13 13:43:38 EDT ---

Since this issue was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Steven Dake on 2014-03-13 14:03:11 EDT ---

Padraig,

Is python-openstackclient planned for packaging in Fedora/RDO?

If it isn't, could you add it to the queue?  Sounds like heat will not support domain functionality without it.

Comment 1 Steven Dake 2014-03-14 16:09:34 UTC
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

Comment 3 Martin Lopes 2014-03-16 23:44:27 UTC
This bug is being assigned to Don Domingo, who is now the designated docs specialist for Heat.

Comment 4 Don Domingo 2014-03-18 01:40:38 UTC
For RHOS5 I'm thinking this should be added to the Installation and Configuration Guide. Changing the component accordingly.

Comment 5 Don Domingo 2014-03-18 01:41:55 UTC
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.

Comment 6 Steven Hardy 2014-04-14 09:21:14 UTC
(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.

Comment 7 Steven Hardy 2014-04-14 15:53:14 UTC
Bug raised to track getting python-openstackclient into RHOS 5.0:

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

Comment 8 Don Domingo 2014-04-16 06:11:31 UTC
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?

Comment 9 Steven Hardy 2014-04-16 07:36:21 UTC
(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 |
+-------------+----------------------------------------------------------------------------------+

Comment 10 Steven Hardy 2014-04-16 09:34:19 UTC
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


Note You need to log in before you can comment on or make changes to this bug.