error status code handling on instana api

[gtfisher]

When running instana experiments the api was returning an error status code due to a malformed url in an environment variable, an error should be logged to clearly identify the error status code has occurred

[russmiles]

Or handled with a better FailedActivity message, such as is done in the Cloud Foundry extension:

https://github.com/chaostoolkit-incubator/chaostoolkit-cloud-foundry/blob/e6efd499b06dfecb3aec26c7d2dcc2a429ff2298/chaoscf/api.py#L49

[russmiles]

When this is in it feels like a good enough set of actions to do a minor, 0.1.1 release. Wdyt @Lawouach ?

[Lawouach]

Agreed on both accounts.

Let's always try to keep the stdout output as clean as possible and focused on the experiment. Doesn't mean we can never use it but it must be in relation to experiment (a dialogue with the operator). Otherwise use the chaostoolkit.log for more information.

For instance:

logger.info(...)

or

logger.error(...)

will send log to the stdout.

Whereas:

logger.debug(...)

writes to the chaostoolkit.log file.

You can therefore do this:

logger.debug("Boom, this thing failed badly: {}".format(str(error_message))
raise ActivityFailed("Your experiment may fail due to an unexpected behavior from the activity

The firest line will write more info into the logfile, the second line will dialogue nicely with the operators settings their expectations.

When you caught an exception and want to lok it:

try
    ...
except Exception:
   logger.debug("Boom, this thing failed badly", exc_info=True)
   raise ActivityFailed("Your experiment may fail due to an unexpected behavior from the activity

This could be described in docs of the toolkit me think :)

[russmiles]

Good point, and we were mulling this here. In this case it's likely that FailedActivity and its message will be right, as it is failed and it is indicative of a fundamental error in trying to talk to Instana.