|Summary:||python-tripleoclient isn't setting the proper region for identity in tempest-deployer-input.conf|
|Product:||Red Hat OpenStack||Reporter:||Arx Cruz <acruz>|
|Component:||python-tripleoclient||Assignee:||Martin Magr <mmagr>|
|Status:||CLOSED ERRATA||QA Contact:||tkammer|
|Version:||9.0 (Mitaka)||CC:||afazekas, dmatthew, dmellado, hbrock, jason.dobies, jjoyce, jschluet, jslagle, mburns, mcornea, mmagr, morazi, psedlak, rhel-osp-director-maint, rhos-maint, tkammer, tvignaud|
|Target Release:||9.0 (Mitaka)|
|Fixed In Version:||python-tripleoclient-2.0.0-4.el7ost||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-03-08 20:06:31 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Arx Cruz 2016-07-18 14:46:53 UTC
Description of problem: python-tripleoclient is the responsible to create the tempest-deployer-input.conf file, and it's not setting the identity.region properly, since tripleo uses regionOne as default region instead of RegionOne. Since this config isn't being provided by tripleo, the tempest assumes his own default to RegionOne, which makes all identity v3 tests fails. Version-Release number of selected component (if applicable): python-tripleoclient-2.0.0-1.0.5.el7ost.noarch Steps to Reproduce: 1. Install OSPD 2. Check tempest-deployer-input.conf if identity.region is set Actual results: identity.region isn't set, making tempest uses the default RegionOne Expected results: identity.region set to regionOne Additional info: There's a patch to change the default region to RegionOne at https://review.openstack.org/#/c/336442/
Comment 8 Dougal Matthews 2016-08-03 14:00:52 UTC
I believe this should be a bug in tripleo-heat-templates. The proposed patch in the bug description (at the bottom of the text) changes the default there. A workaround would be to use an extra heat environment and pass that to openstack overcloud deploy. An example of how to do this looks like this: parameter_defaults: NuageNovaRegionName: RegionOne KeystoneRegion: RegionOne ControllerExtraConfig: RegionOne ceilometer::agent::auth::auth_region: 'RegionOne' aodh::auth::auth_region: 'RegionOne' gnocchi::auth::auth_region: 'RegionOne'
Comment 10 Mike Burns 2016-08-03 14:41:34 UTC
As noted on the upstream review, this has the potential to cause issues with upgrades, changing the region on a deployed system from regionOne to RegionOne. I don't know all the consequences, but this needs to be tested extensively (and even if it passes, I don't know that we'd want to do this). Customers could be driving some of their own operations/queries/etc off of the regionOne name and our changing could negatively impact their custom scripts. Instead of changing the default value, can we consider simply updating the tempest.conf generation to regionOne rather than using it's default or (even better) make the tempest.conf generation read this value from tht?
Comment 12 Martin Magr 2016-08-03 14:53:40 UTC
Ok, BZ just refreshed my list of comment. Now I get why we cannot change wrong default.
Comment 13 Jiri Stransky 2016-08-03 15:03:22 UTC
(In reply to Dougal Matthews from comment #8) > parameter_defaults: > NuageNovaRegionName: RegionOne > KeystoneRegion: RegionOne > ControllerExtraConfig: RegionOne > ceilometer::agent::auth::auth_region: 'RegionOne' > aodh::auth::auth_region: 'RegionOne' > gnocchi::auth::auth_region: 'RegionOne' This alone will probably not do all the necessary things, as the region name isn't an overcloud stack output, and the endpoints are configured via os-cloud-config at the moment. (In reply to Mike Burns from comment #10) > As noted on the upstream review, this has the potential to cause issues with > upgrades, changing the region on a deployed system from regionOne to > RegionOne. I don't know all the consequences, but this needs to be tested > extensively (and even if it passes, I don't know that we'd want to do this). Yes the patch would almost surely not work on upgrades as it is, we'd need to change the upgrade workflow to make it re-apply endpoint creation and possibly add one more step to delete the old endpoints once the cloud is up and running using the new endpoints. And another patch to os-cloud-config would be necessary too. I'm not sure if there could be other potential side effects of switching to a different region name on an existing cloud besides endpoints changing. > > Customers could be driving some of their own operations/queries/etc off of > the regionOne name and our changing could negatively impact their custom > scripts. +1 > > Instead of changing the default value, can we consider simply updating the > tempest.conf generation to regionOne rather than using it's default or (even > better) make the tempest.conf generation read this value from tht? I found http://docs.openstack.org/developer/tempest/sampleconf.html Could we do something like crudini --set /path/to/my/tempest.conf identity region regionOne to make tempest work? (The default is in TripleO for a long time, how have we been running tempest on TripleO until now?) Maybe changing the region name is worth looking into in the long term (?), but as written above, we don't have all the pieces at the moment, and it is probably an invasive operation.
Comment 19 errata-xmlrpc 2017-03-08 20:06:31 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0470.html