cloudapi: More explicit error handling

[croissanne]

In some error cases we need to return a more detailed/well defined (as in, with openapi schemas) error objects.

Specifically if we get depsolve errors in /compose, we currently return an internal server error and the first depsolve error we encounter. It would be better to define an error object in the api spec, so it's more usable in image-builder (and other clients).

[thozza]

I agree with this and would extend it to any errors from image compose. Currently when the compose fails, the cloud api returns only:

{
  "image_status": {
    "status": "failure"
  }
}

regardless if the osbuild run failed or the upload/import to the cloud provider failed or sharing the image with given accounts failed. This makes is hard for the client to actually figure out what happened. Also the current state makes it impossible to present more detailed information in the Image Builder front-end. If the user e.g. made a typo in the AWS account ID to share the image with, they will get just a plain "failure" message. They would not be able to determine whether the failure was caused by their input and thus whether a retry will succeed or whether there is some other issue out of their control.

[teg]

I think it would be nice to enumerate all the error cases we want image builder to report to the user, and what meta-data we want to return for each of them, then implement whatever is necessary to achieve that at the lower levels (as opposed to the lower levels just passing up whatever errors they have and trusting image builder to make sense of it).

[github-actions]

This issue is stale because it had no activity for the past 365 days. Remove the "Stale" label or add a comment, otherwise this issue will be closed in 30 days.