[openstack-dev] [Keystone][Tempest] OS-INHERIT APIs were skipped by Jenkins because "os_inherit" in keystone.conf was disable.
ken1ohmichi at gmail.com
Mon Dec 14 01:43:36 UTC 2015
When adding this extension on https://review.openstack.org/#/c/35986/
, the extension is disabled as the default setting.
Now can we enable this os_inherit extension on Keystone side like
- cfg.BoolOpt('enabled', default=False,
+ cfg.BoolOpt('enabled', default=True,
Or if we don't want to change the default value on Keystone side, we
can enable this os_inherit extension on DevStack side for testing the
extension on Tempest.
This extension has been implemented since 2 years ago, and the API
doc also contains it.
So it is nice to enable it for the development and test, I feel.
2015-12-09 18:03 GMT+09:00 Henry Nash <henrynash9 at mac.com>:
> Hi Maho,
> So in the keystone unit tests, we flip the os_inherit flag back and forth during tests to make sure it is honored correctly. For the tempest case, I don’t think you need to do that level of testing. Setting the os_inherit flag to true will have no effect if you have not created any role assignments that are inherited - you’ll just get the regular assignments back as normal. So provided there is no test data leakage between tests (i.e. old data lying around from a previous test), I think it should be safe to run tempest with os_inherit switched on.
>> On 9 Dec 2015, at 08:45, koshiya maho <koshiya.maho at po.ntts.co.jp> wrote:
>> Hi all,
>> I pushed the patch set of OS-INHERIT API tempest (keystone v3).
>> But, all API tests in patch set was skipped, because "os_inherit" in keystone.conf of
>> Jenkins jobs was disable. So, it couldn't be confirmed.
>> Reference information :
>> Default "os_inherit" setting is disable. OS-INHERIT APIs need "os_inherit" setting enable.
>> For keystone v3 tempests using OS-INHERIT, we should enable "os_inherit" of the existing keystone.conf called by Jenkins.
>> Even if "os_inherit" is enable, I think there have no effects on other tempests.
>> Do you have any other ideas?
>> Thank you and best regards,
>> Maho Koshiya
>> NTT Software Corporation
>> E-Mail : koshiya.maho at po.ntts.co.jp
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev