glance command fails with missing project_id or project_name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Invalid
|
Undecided
|
Unassigned | ||
Newton |
Fix Committed
|
Undecided
|
Pranali Deore | ||
tripleo-common |
New
|
Undecided
|
Pranali Deore |
Bug Description
Glance commands are failing in stable/newton with below error,
You must provide a project_id or project_name (with project_domain_name or project_domain_id) via --os-project-id (env[OS_
Steps to Reproduce:
1. Deploy overcloud
2. Source overcloudrc
3. Run glance command (e.g. glance image-list)
Actual results:
# glance image-list
You must provide a project_id or project_name (with project_domain_name or project_domain_id) via --os-project-id (env[OS_
Expected results:
# glance image-list
+----+------+
| ID | Name |
+----+------+
+----+------+
Additional info:
Older version of tripleo used to generate overcloudrc with 'OS_TENANT_
while since Newton it generates 'OS_PROJECT_
This is happened while moving overcloudrc generation from tripleoclient to a Mistral action which is eventually breaking glanceclient.
This issue is only there in newton, it works fine since ocata because of switching keystoneclient to keystoneauth in glanceclient where tenant specific requirement is removed.
From openstack-
https:/
def create_
...
rc_params = {
...
...
That conflicts with how python-glanceclient checks parameters:
https:/
# Validate password flow auth
project_info = (
args.
)
) or args.os_project_id
)
if not project_info:
# tenant is deprecated in Keystone v3. Use the latest
# terminology instead.
raise exc.CommandError(
_("You must provide a project_id or project_name ("
...
To resolve this conflict, OS_TENANT_NAME needs to be added back in overcloudrc by keeping OS_PROJECT_NAME as it to avoid breaking in any other client.
Changed in tripleo: | |
assignee: | nobody → Pranali Deore (pranali-deore) |
affects: | tripleo → tripleo-common |
Note we no longer use the tripleo-common LP so I added the main tripleo LP to this bug.
Do we know why adding OS_DOMAIN_NAME isn't enough, as from the error message it seems that should work?
If that's not possible then adding the OS_TENANT_NAME alongside the current OS_PROJECT_NAME seems to be the safest option, and is that proposed in https:/ /review. openstack. org/#/c/ 509079/