If user trigger an unlock when stx-openstack is reapplying, the unlock_ready flag should not be removed.
Bug #1837343 reported by
Yan Chen
This bug report is a duplicate of:
Bug #1837750: stx-application re-apply strategy requires some changes.
Edit
Remove
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
StarlingX |
Fix Released
|
Medium
|
Yan Chen |
Bug Description
Test steps:
1. deploy starlingx infrastructure for a simplex system and apply stx-openstack.
2. lock the controller-0.
3. unlock controller-0, this operation will trigger the stx-openstack reapply.
3. before the reapply finished, unlock controller-0 again.
Expected Result:
As stx-openstack is already under reapplying, the new unlock operation will not trigger the reapply again, and the unlock_ready flag should not be removed.
Actual Result:
The reapply is not triggered again.
But unlock_ready flag is removed again, although the flag is already removed by the former unlock.
This is a logic error, though impact is low.
Changed in starlingx: | |
status: | New → Incomplete |
Changed in starlingx: | |
status: | Incomplete → In Progress |
Changed in starlingx: | |
status: | Invalid → Triaged |
To post a comment you must log in.
From the last piece of the attached file, we can see the following log:
2019-07-04 15:46:54.702 112183 INFO sysinv. api.controllers .v1.host [-] controller-0 Action unlock perform notify_mtce api.controllers .v1.host [-] Remove unlock ready flag api.controllers .v1.rest_ api [-] Response= {u'status' : u'pass'} api.controllers .v1.host [-] stx-openstack system app is present but not applied, skipping re-apply
2019-07-04 15:46:54.708 112183 INFO sysinv.
....
2019-07-04 15:46:54.743 112183 INFO sysinv.
2019-07-04 15:46:54.784 112183 INFO sysinv.
Removal of unlock_ready is triggered but app reapply is not.
These 2 operations should be aligned.