Diagnostic Mode

[sciros]

How should we configure the service to run in "diagnostic" mode?

Should we have a diagnostic-mode flag that defaults to False in config.yaml?

Or should we have a diagnostic-mode parameter in the API that, when not present, is the same as it being set to false? So that the API can carry out requests in diagnostic vs production mode on demand, vs having to be reconfigured?

Pros and cons to either approach. Definitely the API becomes more complex and it's unclear whether it's useful for end-user clients to have a "diagnostic" mode that's almost certainly implementation-specific. Then again, the API accepts different parameters (such as perspectives) if it's running in this mode. So the request spec is sensitive to it.

And while we are at it, what else should we be able to freely set that would otherwise fail strict, requirements-aware validation, in "diagnostic" mode? And if there is anything, then should it have separate toggles to disable validation of it?

(There's a lot that needs to be true of a truly valid request. Valid request path, valid validation method, valid quorum count, valid format for things like domain or IP, etc. I don't even have validation for quite all of it in there, quite yet. And then of course all the required fields, like "prefix" etc. depending on the validation method.)

[birgelee]

Per my conversation with @sciros I think the current proposal is there is a top level diagnostic_mode flag. If true, there is an optional diagnostic_params object (name tbd). perspectives can go in diagnostic_params and override perspective_count should it be present. @sciros feel free to comment with your thoughts.

[birgelee]

I believe we are moving this to low priority since simply not acting on the result of the open-mpic query in a CAs logic can be used as an effective diagnostic mode for the time being.