It should be a combination of 2 solutions as solution #2 provides the option to bail while sysinv processes are running a) application thread stalled (e.g. during the cleanup of (test) mariadb pods/stx-openstack namespace issue seen in the past and the system became sluggish) b) client simply wants to abort the operation Solution #2 is more involved than just updating the app state in the database. Tee From: Bailey, Henry Albert (Al) [mailto:Al.Bailey@windriver.com] Sent: June-04-19 8:52 AM To: Chen, Haochuan Z; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] fix solution proposal for LP1826047 Solution 1 sounds like how Openstack Heat handles an abnormal termination of the heat-engine (how it needs to properly clean up its stack locks) Solution 2 is similar to what I have seen for nova and cinder CLI options. Personally, I like option 1. Al From: Chen, Haochuan Z [mailto:haochuan.z.chen@intel.com] Sent: Tuesday, June 04, 2019 1:28 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] fix solution proposal for LP1826047 Hi I am check this launch pad issue. This issue is failed, when system application apply(retrieving docker image), sysinv-api exit unexpected. When service manager re-launch sysinv-api again, application status is in applying status. So application could not be removed. There are two solutions. Solution 1, when sysinv-api or sysinv-conductor launch, in __init__ function, check application status in database, if status is "uploading", "applying" or "removing", change the status to "upload-failed", "apply-failed" or "removed-failed" Solution 2, add perform-abort action for upload or apply. Use a flag to quickly exit and upload and apply action, and set database to "upload-failed" or "apply-failed". https://bugs.launchpad.net/starlingx/+bug/1826047 Wait for brain-storming. Thanks! Martin, Chen SSP, Software Engineer 021-61164330