Admins should not have to drop to CLI for everything related to service checks for the infrastructure portion of an event.
What they should see
Current config, with the checks, args, and point values
Perhaps display the check w/ when it was last edited.
If the check is a text-based script it can be shown as is, else a hash if the check is a binary. This increases visibility among multiple admins, allowing us to find issues with a check much faster.
Any logging that could be shown from the last few check runs is a plus.
How changes should work
Going beyond viewing current configuration, being able to update it is the next priority:
As updating cmd args may be vulnerable, we would want to sanitize the command
This may already be occurring, I haven't verified
Renaming the check must also update all the existing scored results records in the database
This does seem flimsy. We should consider adjusting the schema to use id #s internally, and then lookup the name attached to the challenge in the scorengine.challenges collection for display purposes.
It would be bizarre to go as far as allowing arbitrary scripts to be written on the website and then executed regularly as service checks, although maybe we should simply trust the service's configured admins.
A rollback option would be wonderful
This is only a rough idea as is.
Due to the number of errors that can occur throughout this process, we should be careful with the implementation.
Admins should not have to drop to CLI for everything related to service checks for the infrastructure portion of an event.
What they should see
checks
,args
, andpoint
valuesAny logging that could be shown from the last few check runs is a plus.
How changes should work
Going beyond viewing current configuration, being able to update it is the next priority:
scorengine.challenges
collection for display purposes.This is only a rough idea as is.
Due to the number of errors that can occur throughout this process, we should be careful with the implementation.