Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1357579 - python-tripleoclient isn't setting the proper region for identity in tempest-deployer-input.conf
Summary: python-tripleoclient isn't setting the proper region for identity in tempest-...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-tripleoclient
Version: 9.0 (Mitaka)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: async
: 9.0 (Mitaka)
Assignee: Martin Magr
QA Contact: tkammer
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-18 14:46 UTC by Arx Cruz
Modified: 2018-08-27 11:40 UTC (History)
17 users (show)

Fixed In Version: python-tripleoclient-2.0.0-4.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-08 20:06:31 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0470 normal SHIPPED_LIVE Red Hat OpenStack Platform 9 director Bug Fix Advisory 2017-03-09 01:05:45 UTC
OpenStack gerrit 336442 None None None 2016-08-03 14:01:24 UTC
OpenStack gerrit 350599 None None None 2016-08-03 14:03:17 UTC
OpenStack gerrit 394515 None None None 2016-11-07 16:28:35 UTC

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


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