| 2019-07-15 18:59:43 |
Bin Qian |
bug |
|
|
added bug |
| 2019-07-15 19:05:41 |
Bin Qian |
bug |
|
|
added subscriber John Kung |
| 2019-07-16 15:31:51 |
Ghada Khalil |
tags |
|
stx.containers |
|
| 2019-07-16 15:36:33 |
Ghada Khalil |
starlingx: assignee |
|
Tee Ngo (teewrs) |
|
| 2019-07-16 21:03:07 |
Tee Ngo |
bug |
|
|
added subscriber Dariush Eslimi |
| 2019-07-16 21:04:33 |
Tee Ngo |
starlingx: status |
New |
Incomplete |
|
| 2019-07-17 12:58:38 |
Dariush Eslimi |
bug |
|
|
added subscriber Bart Wensley |
| 2019-07-17 16:53:24 |
Ghada Khalil |
description |
Brief Description
-----------------
After stx-openstack is successfully applied, the application unexpectedly becomes "not applied" after reapply the application failed.
dbmon service is continuously running after stx-openstack reapply failed, however it couldn't reach mariadb cluster as stx-openstack is no long applied/running.
This issue is split from https://bugs.launchpad.net/starlingx/+bug/1829289.
Severity
--------
Major
Steps to Reproduce
------------------
Ref to https://bugs.launchpad.net/starlingx/+bug/1829289
for the steps to reproduce
Expected Behavior
-----------------
When stx-openstack is successfully applied, after a subsequent reapply failed, on both controllers, the system is expected to:
1. stx-openstack will remain as "applied" and run with latest successful configuration.
2. mariadb cluster will be running
3. dbmon service will be able to access and monitor the state of mariadb cluster
Actual Behavior
---------------
stx-openstack application became "not applied" reported by sysinv after reapply failed. Also dbmon repeatedly report it could not access mariadb cluster after reapply failed.
Reproducibility
---------------
Seen once
System Configuration
--------------------
Two node system
Lab-name: IP_5-6
Branch/Pull Time/Commit
-----------------------
stx master as of 20190708T233000Z
Last Pass
---------
Unknown
Timestamp/Logs
--------------
2019-07-10 08:10:05.824 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply completed.
...
2019-07-10 11:01:21.802 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply started.
2019-07-10 11:08:37.690 110608 ERROR sysinv.conductor.kube_app [-] Failed to apply application manifest /manifests/stx-openstack/1.0-17-centos-stable-versioned/stx-openstack-stx-openstack.yaml. See /var/log/armada stx-openstack-apply.log for details.
2019-07-10 11:08:37.696 110608 INFO sysinv.conductor.kube_app [-] Exiting progress monitoring thread for app stx-openstack
2019-07-10 12:17:52.178 228896 INFO sysinv.api.controllers.v1.host [-] stx-openstack system app is present but not applied, skipping re-apply
| 2019-07-10T08:11:06.772 | 290 | service-scn | dbmon | unknown | enabled-active | audit success
| 2019-07-10T11:05:46.432 | 295 | service-scn | dbmon | enabled-active | disabling | audit failed |
Brief Description
-----------------
After stx-openstack is successfully applied, the application unexpectedly becomes "not applied" after reapply the application failed.
dbmon service is continuously running after stx-openstack reapply failed, however it couldn't reach mariadb cluster as stx-openstack is no long applied/running.
This issue is split from https://bugs.launchpad.net/starlingx/+bug/1836075
Severity
--------
Major
Steps to Reproduce
------------------
Ref to https://bugs.launchpad.net/starlingx/+bug/1836075
for the steps to reproduce
Expected Behavior
-----------------
When stx-openstack is successfully applied, after a subsequent reapply failed, on both controllers, the system is expected to:
1. stx-openstack will remain as "applied" and run with latest successful configuration.
2. mariadb cluster will be running
3. dbmon service will be able to access and monitor the state of mariadb cluster
Actual Behavior
---------------
stx-openstack application became "not applied" reported by sysinv after reapply failed. Also dbmon repeatedly report it could not access mariadb cluster after reapply failed.
Reproducibility
---------------
Seen once
System Configuration
--------------------
Two node system
Lab-name: IP_5-6
Branch/Pull Time/Commit
-----------------------
stx master as of 20190708T233000Z
Last Pass
---------
Unknown
Timestamp/Logs
--------------
2019-07-10 08:10:05.824 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply completed.
...
2019-07-10 11:01:21.802 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply started.
2019-07-10 11:08:37.690 110608 ERROR sysinv.conductor.kube_app [-] Failed to apply application manifest /manifests/stx-openstack/1.0-17-centos-stable-versioned/stx-openstack-stx-openstack.yaml. See /var/log/armada stx-openstack-apply.log for details.
2019-07-10 11:08:37.696 110608 INFO sysinv.conductor.kube_app [-] Exiting progress monitoring thread for app stx-openstack
2019-07-10 12:17:52.178 228896 INFO sysinv.api.controllers.v1.host [-] stx-openstack system app is present but not applied, skipping re-apply
| 2019-07-10T08:11:06.772 | 290 | service-scn | dbmon | unknown | enabled-active | audit success
| 2019-07-10T11:05:46.432 | 295 | service-scn | dbmon | enabled-active | disabling | audit failed |
|
| 2019-07-17 17:21:11 |
Dariush Eslimi |
starlingx: assignee |
Tee Ngo (teewrs) |
Bin Qian (bqian20) |
|
| 2019-07-17 18:28:25 |
Bin Qian |
description |
Brief Description
-----------------
After stx-openstack is successfully applied, the application unexpectedly becomes "not applied" after reapply the application failed.
dbmon service is continuously running after stx-openstack reapply failed, however it couldn't reach mariadb cluster as stx-openstack is no long applied/running.
This issue is split from https://bugs.launchpad.net/starlingx/+bug/1836075
Severity
--------
Major
Steps to Reproduce
------------------
Ref to https://bugs.launchpad.net/starlingx/+bug/1836075
for the steps to reproduce
Expected Behavior
-----------------
When stx-openstack is successfully applied, after a subsequent reapply failed, on both controllers, the system is expected to:
1. stx-openstack will remain as "applied" and run with latest successful configuration.
2. mariadb cluster will be running
3. dbmon service will be able to access and monitor the state of mariadb cluster
Actual Behavior
---------------
stx-openstack application became "not applied" reported by sysinv after reapply failed. Also dbmon repeatedly report it could not access mariadb cluster after reapply failed.
Reproducibility
---------------
Seen once
System Configuration
--------------------
Two node system
Lab-name: IP_5-6
Branch/Pull Time/Commit
-----------------------
stx master as of 20190708T233000Z
Last Pass
---------
Unknown
Timestamp/Logs
--------------
2019-07-10 08:10:05.824 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply completed.
...
2019-07-10 11:01:21.802 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply started.
2019-07-10 11:08:37.690 110608 ERROR sysinv.conductor.kube_app [-] Failed to apply application manifest /manifests/stx-openstack/1.0-17-centos-stable-versioned/stx-openstack-stx-openstack.yaml. See /var/log/armada stx-openstack-apply.log for details.
2019-07-10 11:08:37.696 110608 INFO sysinv.conductor.kube_app [-] Exiting progress monitoring thread for app stx-openstack
2019-07-10 12:17:52.178 228896 INFO sysinv.api.controllers.v1.host [-] stx-openstack system app is present but not applied, skipping re-apply
| 2019-07-10T08:11:06.772 | 290 | service-scn | dbmon | unknown | enabled-active | audit success
| 2019-07-10T11:05:46.432 | 295 | service-scn | dbmon | enabled-active | disabling | audit failed |
Brief Description
-----------------
After stx-openstack is successfully applied, the application unexpectedly becomes "not applied" after reapply the application failed.
dbmon service is continuously running after stx-openstack reapply failed, however it couldn't reach mariadb cluster as stx-openstack is no long applied/running.
This issue is split from https://bugs.launchpad.net/starlingx/+bug/1836075
Severity
--------
Major
Steps to Reproduce
------------------
Ref to https://bugs.launchpad.net/starlingx/+bug/1836075
for the steps to reproduce
Expected Behavior
-----------------
When stx-openstack is successfully applied, after a subsequent reapply failed, the system is expected to:
1. stx-openstack will remain as "active" and run with latest successful configuration.
1.1 mariadb cluster will be running and dbmon service will be able to access and monitor the state of mariadb cluster
2. subsequent reapply attempt shall not be rejected
Actual Behavior
---------------
1. stx-openstack application is still active but not running.
1.1 dbmon repeatedly report it could not access mariadb.
2. subsequent reapply was rejected by sysinv: "stx-openstack system app is present but not applied, skipping re-apply"
Reproducibility
---------------
Seen once
System Configuration
--------------------
Two node system
Lab-name: IP_5-6
Branch/Pull Time/Commit
-----------------------
stx master as of 20190708T233000Z
Last Pass
---------
Unknown
Timestamp/Logs
--------------
2019-07-10 08:10:05.824 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply completed.
...
2019-07-10 11:01:21.802 110608 INFO sysinv.conductor.kube_app [-] Application stx-openstack (1.0-17-centos-stable-versioned) apply started.
2019-07-10 11:08:37.690 110608 ERROR sysinv.conductor.kube_app [-] Failed to apply application manifest /manifests/stx-openstack/1.0-17-centos-stable-versioned/stx-openstack-stx-openstack.yaml. See /var/log/armada stx-openstack-apply.log for details.
2019-07-10 11:08:37.696 110608 INFO sysinv.conductor.kube_app [-] Exiting progress monitoring thread for app stx-openstack
2019-07-10 12:17:52.178 228896 INFO sysinv.api.controllers.v1.host [-] stx-openstack system app is present but not applied, skipping re-apply
| 2019-07-10T08:11:06.772 | 290 | service-scn | dbmon | unknown | enabled-active | audit success
| 2019-07-10T11:05:46.432 | 295 | service-scn | dbmon | enabled-active | disabling | audit failed |
|
| 2019-07-18 13:00:53 |
Bin Qian |
bug |
|
|
added subscriber Brent Rowsell |
| 2019-07-22 17:52:35 |
Ghada Khalil |
tags |
stx.containers |
stx.2.0 stx.containers |
|
| 2019-07-22 17:52:40 |
Ghada Khalil |
starlingx: status |
Incomplete |
Triaged |
|
| 2019-07-22 17:52:44 |
Ghada Khalil |
starlingx: importance |
Undecided |
High |
|
| 2019-07-22 17:52:55 |
Ghada Khalil |
starlingx: assignee |
Bin Qian (bqian20) |
Tee Ngo (teewrs) |
|
| 2019-07-24 20:01:29 |
Tee Ngo |
marked as duplicate |
|
1836075 |
|
| 2019-08-23 17:38:25 |
Bin Qian |
attachment added |
|
controller-0_20190823.162133.tar https://bugs.launchpad.net/starlingx/+bug/1836634/+attachment/5284248/+files/controller-0_20190823.162133.tar |
|
| 2019-08-23 17:39:56 |
Bin Qian |
attachment added |
|
controller-1_20190823.161808.tar https://bugs.launchpad.net/starlingx/+bug/1836634/+attachment/5284249/+files/controller-1_20190823.161808.tar |
|
| 2019-08-23 17:40:23 |
Bin Qian |
attachment added |
|
hypervision.PNG https://bugs.launchpad.net/starlingx/+bug/1836634/+attachment/5284250/+files/hypervision.PNG |
|
| 2019-09-10 16:55:44 |
Bill Zvonar |
bug |
|
|
added subscriber Bill Zvonar |
| 2019-10-09 18:25:48 |
Ghada Khalil |
removed duplicate marker |
1836075 |
|
|
| 2019-10-09 18:25:59 |
Ghada Khalil |
marked as duplicate |
|
1836075 |
|
| 2019-10-09 18:44:31 |
Ghada Khalil |
removed duplicate marker |
1836075 |
|
|
| 2019-10-09 18:44:37 |
Ghada Khalil |
starlingx: status |
Triaged |
Fix Released |
|
| 2019-10-09 18:44:48 |
Ghada Khalil |
marked as duplicate |
|
1836075 |
|
