Existing AMI generation flow has few limitations and issues (linked below) which brought to the effort to redesign it completely to enable:

• better customer experience
• better visibility and debugability
• multiple image future support

Current flow : Create podvm image -> create mcp, kata rpm etc -> create kata runtimeclass -> create kata-remote runtimeclass

New flow: create mcp, kata rpm etc -> create kata runtimeclass -> create podvm image -> create kata-remote runtimeclass

The image generation status events are posted as Kubernetes events for monitoring
Kataconfig  inProgress status should be used to monitor AMI progress and to contain proper reason and message for AMI job creation/deletion:

status:
  conditions:
  - lastTransitionTime: "2024-02-23T09:04:01Z"
    message: Creating Pod VM Image
    reason: PodVMImageJobRunning
    status: "True"
    type: InProgress