yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #92547
[Bug 2025146] [NEW] There is a confusion in priority between when clouds.yml parameters are used and when the exported variables are used
Public bug reported:
Description of problem:
In the past (OSP less then 17.1 +SRBAC configuration)
we were able to use only the rc file if we wanted to source the user, without the need to update the clouds.yml and with no obligation to put other value in the OS_CLOUD filed.
Version-Release number of selected component (if applicable):
RHOS-17.1-RHEL-9-20230607.n.2 +SRBAC configuration
How reproducible:
Every time, in the same session.
Steps to Reproduce:
Prerequisites:
1.Create a project under the default domain (fro example "project2"
2.Create the user:
(overcloud) [stack@undercloud-0 ~]$ openstack user create admin3 --password 12345678
3.Add a role to the user-
(overcloud) [stack@undercloud-0 ~]$ openstack role add --user admin3 --project project2 admin
3.Make sure the user is assign with the right role-
(overcloud) [stack@undercloud-0 ~]$ openstack role assignment list --user admin3 --names
4.Copy the overcloudrc file and give it a new name like "admin3rc"
5.Change the file’s fields to be compatible to the new user.
6.***In this point, if we don't change the clouds.yml file, this user will not be able to send requests.***- This is new -Is it part of the bug?
7. Change the clouds.yml - Add the new user and make sure the user's name is right above auth: in the clouds.yml file+ make sure the same name is the same as in the field of "OS_CLOUD=" of the admin3rc file. This is the way it should be:"OS_CLOUD=admin3"
8.Sourcing admin3rc and sending regular commands in a new session when all env variables are empty will end successfully-
[stack@undercloud-0 ~]$ . admin3rc
(admin3) [stack@undercloud-0 ~]$ openstack user list
+----------------------------------+-------------------------------------------------------------------+
| ID | Name |
+----------------------------------+-------------------------------------------------------------------+
| 1735403404384416876f68c51c0388c7 | admin |
| 2b82835faf1b4f479cd0395036dcd677 | barbican |
....
..
.
Leaving overcloud in the OS_CLOUD filed e.g. export OS_CLOUD=overcloud in the admin3rc file, will make a confution in this scenario:
Steps:
1. [stack@undercloud-0 ~]$ . admin3rc
2. (overcloud) [stack@undercloud-0 ~]$ openstack user list
The request you have made requires authentication. (HTTP 401) (Request-ID: req-fa114d20-5492-4e61-bfc9-6f9586b8aafe)
Actual results:
There is a confusion in priority between when clouds.yml parameters are used and when the exported variables are used. We get the error "The request you have made requires authentication. (HTTP 401) "
Expected results:
The action should end successfully.
If the behavior was not changed, we need to be able to use only the rc file if we want to , without the need to update the clouds.yml and with no obligation to put other value in the OS_CLOUD filed.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/2025146
Title:
There is a confusion in priority between when clouds.yml parameters
are used and when the exported variables are used
Status in OpenStack Identity (keystone):
New
Bug description:
Description of problem:
In the past (OSP less then 17.1 +SRBAC configuration)
we were able to use only the rc file if we wanted to source the user, without the need to update the clouds.yml and with no obligation to put other value in the OS_CLOUD filed.
Version-Release number of selected component (if applicable):
RHOS-17.1-RHEL-9-20230607.n.2 +SRBAC configuration
How reproducible:
Every time, in the same session.
Steps to Reproduce:
Prerequisites:
1.Create a project under the default domain (fro example "project2"
2.Create the user:
(overcloud) [stack@undercloud-0 ~]$ openstack user create admin3 --password 12345678
3.Add a role to the user-
(overcloud) [stack@undercloud-0 ~]$ openstack role add --user admin3 --project project2 admin
3.Make sure the user is assign with the right role-
(overcloud) [stack@undercloud-0 ~]$ openstack role assignment list --user admin3 --names
4.Copy the overcloudrc file and give it a new name like "admin3rc"
5.Change the file’s fields to be compatible to the new user.
6.***In this point, if we don't change the clouds.yml file, this user will not be able to send requests.***- This is new -Is it part of the bug?
7. Change the clouds.yml - Add the new user and make sure the user's name is right above auth: in the clouds.yml file+ make sure the same name is the same as in the field of "OS_CLOUD=" of the admin3rc file. This is the way it should be:"OS_CLOUD=admin3"
8.Sourcing admin3rc and sending regular commands in a new session when all env variables are empty will end successfully-
[stack@undercloud-0 ~]$ . admin3rc
(admin3) [stack@undercloud-0 ~]$ openstack user list
+----------------------------------+-------------------------------------------------------------------+
| ID | Name |
+----------------------------------+-------------------------------------------------------------------+
| 1735403404384416876f68c51c0388c7 | admin |
| 2b82835faf1b4f479cd0395036dcd677 | barbican |
....
..
.
Leaving overcloud in the OS_CLOUD filed e.g. export OS_CLOUD=overcloud in the admin3rc file, will make a confution in this scenario:
Steps:
1. [stack@undercloud-0 ~]$ . admin3rc
2. (overcloud) [stack@undercloud-0 ~]$ openstack user list
The request you have made requires authentication. (HTTP 401) (Request-ID: req-fa114d20-5492-4e61-bfc9-6f9586b8aafe)
Actual results:
There is a confusion in priority between when clouds.yml parameters are used and when the exported variables are used. We get the error "The request you have made requires authentication. (HTTP 401) "
Expected results:
The action should end successfully.
If the behavior was not changed, we need to be able to use only the rc file if we want to , without the need to update the clouds.yml and with no obligation to put other value in the OS_CLOUD filed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2025146/+subscriptions