[identity] It is possible to encounter databag item name collision in 'user' databag
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack + Chef |
Confirmed
|
Wishlist
|
Sharat Sharma |
Bug Description
In current cookbooks implementation, when trying to get passwords in user databag (or say the databag defined for user, because it is able to set custom databag, and set that custom databag name in environment in [''openstack]
admin_pass = get_password 'user', node['openstack
The databag item name is dynamic according to the second argument in get_password method. If the databag names happen to have a collision, that means those conflict databag items must have the same password.
Why not identify static databag item for each use case, instead of like:
admin_pass = get_password 'user', 'identity_admin'
and add such 'identity_admin' databag item into 'user' databag, so that the databag item name collision can be avoided.
Changed in openstack-chef: | |
milestone: | none → kilo-rc1 |
importance: | Medium → Wishlist |
summary: |
- It is possible to encounter databag item name collision in 'user' - databag + [identity] It is possible to encounter databag item name collision in + 'user' databag |
tags: | added: common identity |
Changed in openstack-chef: | |
milestone: | kilo-rc1 → none |
Changed in openstack-chef: | |
assignee: | nobody → Sharat Sharma (sharat-sharma) |
After looking around the cookbooks, I see that the messaging and san_login passwords would be a great place to start for this work.
For messaging, they are handled like this:
cookbook- openstack- orchestration/ recipes/ common. rb: mq_password = get_password 'user', node['openstack ']['mq' ]['orchestratio n']['rabbit' ]['userid' ] openstack- orchestration/ recipes/ common. rb: mq_password = get_password 'user', node['openstack ']['mq' ]['orchestratio n']['qpid' ]['username' ]
cookbook-
That could be reduced to:
cookbook- openstack- orchestration/ recipes/ common. rb: mq_password = get_password 'user', 'mq_password'
This would effect the following cookbooks:
Common - for doc updates
Image, Network, Orchestration, Database, Compute, Block-Storag, Ops-Messaging, Telemetry
For the san_login, that is used like this today:
cookbook- openstack- block-storage/ recipes/ cinder- common. rb: storwize_pass = get_password 'user', node['openstack ']['block- storage' ]['storwize' ]['san_ login'] openstack- block-storage/ recipes/ cinder- common. rb: solidfire_pass = get_password 'user', node['openstack ']['block- storage' ]['solidfire' ]['san_ login'] openstack- block-storage/ recipes/ cinder- common. rb: ibmnas_pass = get_password 'user', node['openstack ']['block- storage' ]['ibmnas' ]['nas_ login']
cookbook-
cookbook-
That would be changed to something like:
cookbook- openstack- block-storage/ recipes/ cinder- common. rb: san_login_pass = get_password 'user', 'san_login'
This would effect the Common cookbook for maybe some doc and the Block-Storage cookbook.
So the net is that this should probably be broken down in to at least 3 groups of changes, one for messaging password, one for san_login password, and one for possibly doing the component user passwords. Does that sound about right?