Lockout of keystone admin user is not disabled on upgrades
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
StarlingX |
Fix Released
|
Medium
|
Andy |
Bug Description
Brief Description
-----------------
This is a follow-up on https:/
If an upgrade is attempted from an n build (which doesn't have the above fix i.e. doesn't prevent the lockout of the keystone admin user) to an n+1 build (which has the fix), the admin user can still be locked out after the upgrade. This is inconsistent with doing a fresh install of the n+1 build.
The code to disable the user lockout was not included as a step in the upgrade migration.
Severity
--------
Minor - LP is opened for completeness to address the inconsistency in behavior
Steps to Reproduce
------------------
See the description. This has to be simulated by attempting a non-null upgrade.
Expected Behavior
------------------
The keystone admin user is setup the same way after an upgrade as it is after a fresh install
Actual Behavior
----------------
The keystone admin user can be locked out after an upgrade to a build which has the original fix
Reproducibility
---------------
100% reproducible
System Configuration
-------
Any
Branch/Pull Time/Commit
-------
Any load since 2020-05-28
Last Pass
---------
Never
Timestamp/Logs
--------------
NA
Test Activity
-------------
Upgrades Developer Testing
Workaround
----------
TBD - this can manually be updated after the upgrade. Exact procedure is TBD.
Changed in starlingx: | |
assignee: | nobody → Andy (andy.wrs) |
tags: | added: stx.5.0 stx.config stx.update |
Changed in starlingx: | |
importance: | Undecided → Medium |
status: | New → Triaged |
description: | updated |
Changed in starlingx: | |
importance: | Medium → Low |
description: | updated |
tags: | added: in-r-stx40 |
Changed in starlingx: | |
status: | Fix Released → In Progress |
tags: | removed: in-r-stx40 |
tags: | added: in-r-stx40 |
Fix proposed to branch: master /review. opendev. org/741662
Review: https:/