Bug 1790593 - "openstack role add" command should not accept Domain ID in --project parameter
Summary: "openstack role add" command should not accept Domain ID in --project parameter
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-openstackclient
Version: 13.0 (Queens)
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Harry Rybacki
QA Contact: Jeremy Agee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-13 16:57 UTC by Ignacio
Modified: 2023-09-07 21:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 20:18:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1860478 0 None None None 2020-01-21 20:02:40 UTC
OpenStack Storyboard 2007194 0 None None None 2020-01-21 20:02:40 UTC

Description Ignacio 2020-01-13 16:57:24 UTC
Description of problem:

Command "openstack role add" does not accept Domain name for parameter --project:
(overcloud) [stack@undercloud-0 ~]$ openstack role add --user user1 --user-domain Domain1 --project Domain1  --project-domain Domain1 --inherited ResellerAdmin
No project with a name or ID of 'Domain1' exists.

But it accepts Domain-ID, in this example:
(overcloud) [stack@undercloud-0 ~]$ openstack domain list
+----------------------------------+------------+---------+--------------------+
| ID                               | Name       | Enabled | Description        |
+----------------------------------+------------+---------+--------------------+
| 810677bd34654a9f8fafd29dea87f72f | Domain1    | True    |                    |
| 89900233b61b4267846cb687d7839140 | heat_stack | True    |                    |
| default                          | Default    | True    | The default domain |
+----------------------------------+------------+---------+--------------------+

So changing Dmain1 by 810677bd34654a9f8fafd29dea87f72f:
(overcloud) [stack@undercloud-0 ~]$ openstack role add --user user1 --user-domain Domain1 --project 810677bd34654a9f8fafd29dea87f72f  --project-domain Domain1 --inherited ResellerAdmin

After this, trying to list, we got ERROR which probably is caused by previous action which should be allowed:
(overcloud) [stack@undercloud-0 ~]$ openstack role assignment list --user-domain Domain1 --user user1 --names
object of type 'NoneType' has no len() (HTTP 400) (Request-ID: req-8563b7e6-77da-4df1-971c-83c744d4e564)

Version-Release number of selected component (if applicable):
[root@undercloud-0 ~]# rpm -qa | grep python-openstackclient
python-openstackclient-lang-3.14.3-4.el7ost.noarch


How reproducible:
100%

Steps to Reproduce:
$ openstack domain create Domain1
$ openstack user create user1 --domain Domain1 --password-prompt
$ openstack project create Project1 --domain Domain1 
$ openstack project create SubProject1 --parent Project1 --domain Domain1
$ openstack role add --user user1 --user-domain Domain1 --project Domain1  --project-domain Domain1 --inherited ResellerAdmin -->ERROR
$ openstack role add --user user1 --user-domain Domain1 --project 810677bd34654a9f8fafd29dea87f72f  --project-domain Domain1 --inherited ResellerAdmin --> NO ERROR (but it should be ERROR as well)


Actual results:
"openstack role add" command accepts Domain ID in --project parameter


Expected results:
"openstack role add" command does not accept Domain ID in --project parameter

Additional info:

Comment 1 Harry Rybacki 2020-01-21 20:02:40 UTC
Ignacio, thanks for bringing this to our attention. I've confirmed this is a bug and is affecting the current release. I'm working with upstream to determine the best backwards compatible solution.

I'm adding trackers for the LP[1] and Storyboard story[2] where we will track this upstream.

[1] - https://bugs.launchpad.net/keystone/+bug/1860478
[2] - https://storyboard.openstack.org/#!/story/2007194

Comment 2 Raildo Mascena de Sousa Filho 2020-03-27 20:18:05 UTC
Hi folks, 


Since this is a low priority and it has been tracked upstream as a launchpad, we will be following that fix only in the upstream side, I'm closing based on our capacity/priority.


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