Description

the AMI ID or Azure Image ID creation during the kataconfig creation/deletion has a specific workflow which has a few edge cases listed below. The entire flow is dependent on the job to create/delete these podmv image to succeed for it to continue the install of kataconfig (or the deletion)

• If there is an existing podvm Image with the name 'peer-pod-XXXX' (on the cloud provider) the kataconfig install does not begin as the IMAGE ID creation job fails (due to the same name of the existing podvm image) and that causes the kataconfig install to be stuck in and there is no progress

• If by mistake the user deletes the podvm IMAGE  (from the console of the cloud provider ) the kataconfig deletion will not progress as the process waits for the image deletion job to complete which it wont in this case as the user has deleted the podvm image already and the job fails , unable to find the podvm image id. 

  Steps to reproduce

Tested on AWS
1. Create an AMI with the name peer-pod-ami and try installing kataconfig
2. Delete the AMI named peer-pod-ami and try deleting kataconfig

Expected result

These have not been handled yet so there isnt any expected result.

From a user pov

• I expect the kataconfig delete to overlook if the podvm image id isnt found and continue with the deletion
• The install case a check can be performed if any existing AMI ID exists and handle it accordingly

Actual result

Failure

Impact

Bad user experience

Env

<Where was the bug found, i.e. OCP build, operator build, kata-containers build, cluster infra, test case id>

Additional helpful info

<logs, screenshot, doc links, etc.>