Improve granularity of error reporting for Kubernetes Manifest Apply operations

[leecalcote]

Current Behavior

This code is used when deploying Meshery Designs: utils/kubernetes/apply-manifest.go. The response collected on error from Kubernetes is not overly insightful or offering of details necessary for users to identify a resolution to deployment failure.

Desired Behavior

When applying a Kubernetes manifest, the Kubernetes API can return several different responses. These responses generally fall into a few categories:

Success Responses:

• created: This indicates that the resource defined in the manifest was successfully created.
• configured: This indicates that the resource already existed but was modified according to your manifest.
• unchanged: This indicates that the resource already existed and matched the manifest exactly, so no changes were made.

Error Responses:

• Invalid: This indicates that the manifest you provided was invalid. This could be due to syntax errors, missing required fields, or invalid values. The error message should provide more details about the problem.
• AlreadyExists: This indicates that you are trying to create a resource that already exists with the same name and namespace. You may need to update the existing resource instead.
• Forbidden: This indicates that you do not have the necessary permissions to create or modify the resource. You may need to contact your cluster administrator.
• Conflict: This indicates that the resource you are trying to modify has been updated by someone else since you last retrieved it. You will need to retrieve the latest version of the resource and reapply your changes.
• ServerTimeout: This indicates that the API server was unable to process your request within the allowed time. You may need to increase the timeout value or try again later.
• InternalError: This indicates that an unexpected error occurred on the server. You may need to contact your cluster administrator.

Other Responses:

• Warnings: In some cases, the API server may return a success response along with warnings. These warnings indicate potential issues that you may want to address, but they do not prevent the resource from being created or modified.

HTTP Status Codes:

In addition to the above responses, the Kubernetes API also returns standard HTTP status codes. These codes provide more information about the nature of the response. Some common codes include:

• 200 OK: The request was successful.
• 201 Created: The resource was successfully created.
• 400 Bad Request: The request was invalid.
• 403 Forbidden: You do not have the necessary permissions.
• 409 Conflict: The request conflicts with the current state of the resource.
• 500 Internal Server Error: An unexpected error occurred on the server.

It's important that MeshKit functions understand these possible responses and report them back to users/their calling functions (from Meshery Server), so that users can troubleshoot issues and ensure their designs have properly configured components, compatible with their Kubernetes clusters.

The current experience is underwhelming and leaves users pondering what to do next when their deployment doesn't succeed.

The response to users should be clear in terms of which components were deployed and which were not. Here is an example of the current experience: