commit f69b1312949828f5852b06c42c2331e561df5c4b
Author: Tyler Smith <email address hidden>
Date: Wed Aug 21 18:07:34 2019 -0400
Changes to stx-openstack application automatic re-apply behaviour
The stx-openstack application is no longer automatically reapplied
on node unlock. The new behaviour is handled with a reapply flag:
- When a node is unlocked, or a runtime manifest is applied,
overrides are regenerated and compared to
their old values. If there is a difference a reapply flag is raised
along with a warning alarm
- A check was added to the kubernetes audit in the sysinv conductor
to check if the reapply flag has been raised and to trigger a reapply
if the system is in a stable state (no hosts currently locking/unlocking/booting)
- This check is also done when a runtime manifest reports success
Test cases:
AIO-SX, AIO-DX, and Standard:
- When a lock/unlock is done with no changes the application is
not reapplied
- When a lock/unlock is done after a config change is made the
application waits until after the unlock and then triggers a reapply
STANDARD
- Enabled ceph-rgw chart and ensured that the application was reapplied upon
config success (likewise for chart disable)
- If there is a pending reapply, and the user triggers it before the
system is stable the reapply flag and alarm are removed
- Provisioning a new compute node and unlocking it for the
first time triggers an application reapply after it comes online
- App is reapplied when a node is deleted
- Compute added without node labels and unlocked results in no reapply
- Compute locked, labels applied, then unlocked results in a reapply
pods launch on compute only when labels present (likewise for label removal)
- Pending reapply flag and alarm persist over a controller swact
Change-Id: I1ae9fdc2afcdf831cf0e7d96f8af14fcb5f6b579
Closes-Bug: 1837750
Depends-On: https://review.opendev.org/#/c/678232
Signed-off-by: Tyler Smith <email address hidden>
(cherry picked from commit b1895200a44986b1a447c28262bf22edeba5f652)
Reviewed: https:/ /review. opendev. org/678233 /git.openstack. org/cgit/ starlingx/ config/ commit/ ?id=f69b1312949 828f5852b06c42c 2331e561df5c4b
Committed: https:/
Submitter: Zuul
Branch: r/stx.2.0
commit f69b1312949828f 5852b06c42c2331 e561df5c4b
Author: Tyler Smith <email address hidden>
Date: Wed Aug 21 18:07:34 2019 -0400
Changes to stx-openstack application automatic re-apply behaviour
The stx-openstack application is no longer automatically reapplied
on node unlock. The new behaviour is handled with a reapply flag:
- When a node is unlocked, or a runtime manifest is applied,
locking/ unlocking/ booting)
overrides are regenerated and compared to
their old values. If there is a difference a reapply flag is raised
along with a warning alarm
- A check was added to the kubernetes audit in the sysinv conductor
to check if the reapply flag has been raised and to trigger a reapply
if the system is in a stable state (no hosts currently
- This check is also done when a runtime manifest reports success
Test cases:
AIO-SX, AIO-DX, and Standard:
- When a lock/unlock is done with no changes the application is
not reapplied
- When a lock/unlock is done after a config change is made the
application waits until after the unlock and then triggers a reapply
STANDARD
- Enabled ceph-rgw chart and ensured that the application was reapplied upon
config success (likewise for chart disable)
- If there is a pending reapply, and the user triggers it before the
system is stable the reapply flag and alarm are removed
- Provisioning a new compute node and unlocking it for the
first time triggers an application reapply after it comes online
- App is reapplied when a node is deleted
- Compute added without node labels and unlocked results in no reapply
- Compute locked, labels applied, then unlocked results in a reapply
pods launch on compute only when labels present (likewise for label removal)
- Pending reapply flag and alarm persist over a controller swact
Change-Id: I1ae9fdc2afcdf8 31cf0e7d96f8af1 4fcb5f6b579 /review. opendev. org/#/c/ 678232 1a447c28262bf22 edeba5f652)
Closes-Bug: 1837750
Depends-On: https:/
Signed-off-by: Tyler Smith <email address hidden>
(cherry picked from commit b1895200a44986b