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