Setup Checks

Setup Checks Objectives

• Performance-related:
  • Identify the next partition for a set of checks to run against - just once, rather than in each check
  • Prepare data for faster processing by table checks - perhaps by aggregating it, or extracting a subset of data (changed or random) from a large non-partitioned table into a smaller table
• Control-flow-related:
  • Identify whether or not to run checks at all - if no data has changed since the last run
• Further references:
  • Sample & reusable checks on hadoopinspector_plugins

Setup Check Requirements

• Must be in check_dir
• Filename must start with 'setup_'
• Must be identified within registry file for table with a check_type of 'setup'
• Otherwise can be in written in any language

Runner to Setup Interface:

• All communication is through environmental variables set by the runner.
• Since the setup may be provided by the local user, it can implement other methods of control - its own config file, etc.
• Environmental variables set by the runner for a setup check:
  • hapinsp_instance
  • hapinsp_database
  • hapinsp_table
  • hapinsp_check_mode - from registry
  • hapinsp_tablecustom_internal_rc_prior - from same setup check on the prior run
  • hapinsp_tablecustom_[setup var name]_prior - from same setup check on the prior run

Setup to Runner Interface:

• All communication back to the runner is through a JSON structure printed by the setup check - and captured by the runner. The only other data captured by the runner is the setup's return code.
• Example JSON struct printed by setup:
  • { "rc": "?", "table_status": "inactive", "hapinsp_tablecustom_[setup var name]": "foo", "hapinsp_tablecustom_[setup_var_name]": "bar" }
• JSON fields:
  • table_status - must be either 'active' or 'inactive'. If 'inactive', then the runner will not run any checks for this table.
  • hapinsp_table_mode - must be one of ['full', 'incremental', or 'auto']. Will be exported as env var for all checks to access.
  • hapinsp_tablecustom_* - the runner will export these as environmental variables. They'll persist until the end of testing for this table, then be automatically torn-down by the runner.