Red Hat Bugzilla – Bug 1059126
[Doc] Overall manual install guide can be greatly simplified
Last modified: 2014-10-30 18:29:47 EDT
All, I have only spotted this issue across the manual installation doc, but it might apply to many other docs. Also, I will show an example here, but it applies to all services described in the doc, both for using keystone to manage accounts and services such as neutron. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/Creating_the_Permanent_Service_Endpoint.html (chapter 9.6) Let´s unroll from point 3 (create a service entry) # keystone service-create --name=keystone --type=identity \ --description="Keystone Identity Service" +-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Keystone Identity Service | | id | a8bff1db381f4751bd8ac126464511ae | | name | keystone | | type | identity | +-------------+----------------------------------+ ^^^^^this step is ok point 4: keystone endpoint-create \ --service_id ID \ --publicurl 'http://IP:5000/v2.0' \ --adminurl 'http://IP:35357/v2.0' \ --internalurl 'http://IP:5000/v2.0' would unfold to: keystone endpoint-create \ --service_id a8bff1db381f4751bd8ac126464511ae \ --publicurl 'http://IP:5000/v2.0' \ --adminurl 'http://IP:35357/v2.0' \ --internalurl 'http://IP:5000/v2.0' here is the first problem. You are using --service_id. This requires a user to input "a8bff1db381f4751bd8ac126464511ae" that while it can be copy/pasted manually is not easily scriptable (for repeatable deployments). Instead we should suggest: keystone endpoint-create \ --service keystone \ --publicurl 'http://IP:5000/v2.0' \ --adminurl 'http://IP:35357/v2.0' \ --internalurl 'http://IP:5000/v2.0' --service will take the name, it´s intuitive for the admin and it has the same effect. Similar for user account creation on chap 9.7 OK> keystone user-create --name admin --pass PASSWORD OK> keystone role-create --name admin OK> keystone tenant-create --name admin NOT OK> keystone user-role-add --user-id USERID --role-id ROLEID --tenant-id TENANTID you need to input 3 hashes, instead of: keystone user-role-add --user admin --role admin --tenant admin One more example that would shorten the documentation and steps a lot in 11.4.2 (it applies to all services): OK> source ~/keystonerc_admin OK> keystone user-create --name glance --pass PASSWORD remove "role-get admin" and "tenant-list". Simply replace them with: "If you didn´t configure admin role and service tenant - read here" NOK> keystone user-role-add --user-id USERID --role-id ROLEID --tenant-id TENANTID keystone user-role-add --user glance --role admin --tenant services etc. etc. etc. etc. The use of hashes as references is scary :) and not very easy to debug when you copy paste the wrong one.
Changed ALL the keystone setup instructions for all services in the ICG so we no longer use IDs when specifying service, user, role; instead, we use the "name" value of each item. Other changes: - for each service, specified services tenant and admin role prerequisites. Also included links to instructions for setting up admin account and services tenant. - for Telemetry and Orchestration, added step to set up shell environment to access Keystone as Admin (i.e. 'source ~/keystonerc_admin') - changed keystone setup instructions for cinder to be more consistent with others (now "Creating the Block Storage Service Identity Records").
Here are all the sections that changed: Creating the Identity Service Endpoint Creating an Administrator Account Creating the Block Storage Service Identity Records Creating the Image Identity Records Creating the OpenStack Networking Identity Records Creating the Compute Identity Records Creating the Orchestration Service Identity Records Creating the Telemetry Identity Records Will get add links for QE once a rebuild is done.
Fabio, It just occurred to me that using tenant/role/user IDs might be required in case that another entry with a similar name exists in the DB. Or does the Identity service require that all tenant/role/user names be unique?
(In reply to Don Domingo from comment #4) > Fabio, > > It just occurred to me that using tenant/role/user IDs might be required in > case that another entry with a similar name exists in the DB. Or does the > Identity service require that all tenant/role/user names be unique? [root@rhos4-keystone1 ~(keystone_admin)]$ keystone user-list |grep fabbione | 79dff35a63ee49929ab141a2233e191b | fabbione | True | | [root@rhos4-keystone1 ~(keystone_admin)]$ keystone user-create --name fabbione --pass test Conflict occurred attempting to store user. (1062, "Duplicate entry 'default-fabbione' for key 'domain_id'") (HTTP 409) So name have to be unique within the same region.
(In reply to Don Domingo from comment #3) > Here are all the sections that changed: > > Creating the Identity Service Endpoint > Creating an Administrator Account > Creating the Block Storage Service Identity Records > Creating the Image Identity Records > Creating the OpenStack Networking Identity Records > Creating the Compute Identity Records > Creating the Orchestration Service Identity Records > Creating the Telemetry Identity Records > > Will get add links for QE once a rebuild is done. Perhaps I am wrong, but isn't the Object storage missing from this list?
Sorry, forgot to list it. Fixed that one as well, and in the process changed the title to "Creating the Object Storage Service Identity Records" (it used to be "Configuring the Identity Service to work with the Object Storage Service"). (In reply to Fabio Massimo Di Nitto from comment #6) > Perhaps I am wrong, but isn't the Object storage missing from this list?