RFE: Have a standard way to report errors

[nmasse-itix]

The 3scale toolbox is being improved to become the recommended way to configure and deploy services in 3scale. This fits in a broader approach of Continuous Delivery that has been started by several customers / communities (I personally maintain the threescale-cicd ansible role. Those approaches are using different means to drive the 3scale admin portal, some are using the 3scale-cli other (like the threescale-cicd role) are using the 3scale REST APIs.

If we want to make the 3scale_toolbox the de facto standard for interacting with 3scale, we need it to be usable in a CI/CD approach.

At a glance, here are the features I expect from the 3scale toolbox :

• RFE: Make the toolbox idempotent #81: Is idempotent
• RFE: Working with system_name and not id #82: Works with system_name and not service_id
• RFE: Provide a parseable output (JSON / YAML) #83: Can output human readable information as well as json or yaml (akin to oc cmd -o yaml)
• RFE: Have a standard way to report errors #80: Have a standard way to report errors

A standard way to report errors

Since the 3scale toolbox will be used from scripts / pipelines / etc, any error must be reported without any ambiguity.

Proposition

The plugins have a standard way to report errors, the unix return code is set appropriately and the output can be parsed easily by a script (JSON / YAML for instance).

Examples

If the requested operation cannot be completed, the Unix return code is > 1 and if the operation has been completed successfully the Unix return code is 0.
If the requested operation cannot be completed, the output would look like :

{
  "error_code": "E_CANNOT_READ_OPENAPI",
  "error_message": "Cannot parse OpenAPI Specs: missing field bla bla bla",
  "kind": "local",
  "stacktrace": "..."
}

This feature needs to be in the toolbox's core so that every plugin can leverage this feature.

[eguzki]

👍

Reasonable and acceptable

[eguzki]

We implemented a global error handler #73. We defined a set of expected errors. When an expected error accurs, simple output message is generated. On the other hand, when unexpected error occurs, report with stacktrace and environment information is generated both on screen (stderr) and in a crash.log file

But did not define any output format and can be, indeed, valuable.