Red Hat Bugzilla – Bug 1464547
OS_TENANT_NAME is replaced with OS_PROJECT_NAME in overcloudrc
Last modified: 2017-06-29 14:07:36 EDT
Description of problem: Our scripting depended on OS_TENANT_NAME being in the overcloudrc, which is the case with the version of OSP10 on CDN. In the RC puddle, OS_TENANT_NAME has been replaced with OS_PROJECT_NAME in the overcloudrc. Version-Release number of selected component (if applicable): http://download-node-02.eng.bos.redhat.com/rcm-guest/puddles/OpenStack/10.0-RHEL-7/2017-06-19.1/ How reproducible: Do an overcloud deployment, then look in the overcloudrc. Steps to Reproduce: See above. Actual results: OS_TENANT_NAME is missing from the overcloudrc Expected results: OS_TENANT_NAME should be present in the rc? Additional info:
It seems like if OS_TENANT_NAME has been deprecated, then it's ok to remove it from the overcloudrc. If it hasn't yet been deprecated, then it seems like it should be in that file. Just my 2 cents.
OS_TENANT_NAME was deprecated in the Kilo release. OS_PROJECT_NAME is the preferred variable. I am unclear how OSP10 would generate OS_TENANT_NAME but a puddle would generate something different.
I see where it was introduced... The overcloudrc generation code was moved to tripleo-common, but wasn't actually utilized from the client. The move to use that was backported here: https://review.openstack.org/#/c/410272/ OS_PROJECT_NAME is the proper variable to use.
I understand, but all customers that have OSP10 installed have OS_TENANT_NAME in their overcloudrc, and not OS_PROJECT_NAME. If this ships as-is, then as soon as they do a yum update, their CLIs will be instantly be broken, generating support calls. As I mentioned before, I already patched our scripting so we are not affected by the change. Just trying to help out here.
How are the CLIs broken by the change? They are effectively the same thing (or at least should be). Do you have some specific problems that you saw?
Ah - sorry, I'm getting issues confused. As far as I'm aware, the only issue is that code that depends on OS_TENANT_NAME being present will no longer work. This is what happened to us.
As long as it doesn't actually break anything, we consider this an implementation detail and not a breaking change. Thanks for the report. I will add some doctext on this bug so it can at least be captured in release notes.