[PS-Module] Specifications, Constraints, Assumptions

[vScripter]

Specifications, Assumptions & Constraints (SAC)

The description of this issue will serve as the curated list of Specs, Constraints & Assumptions for the PS-Module of vCheck.

Module Layout

Specifications

Must Support

• Simplicity
  • Make it as easy as possible to both run the report and develop a plugin
  • An example of this would be simply adding the plugin directory to /Plugins - this would allow people to expand the functionality to suit their needs, without having plugins that people might not use baked in/embedded into the main vCheck module
• Don't use numbers as a file prefix
  • for plugin/function names (it doesn't scale and it makes people guess on where they should start numbering for a new plugin)
• Scope
  • Keep plugin configuration limited to the scope of the plugin/plugin functions
• Configuration Flow
  • Make it easier to understand (and consume) configurations (variables) that are globally available for use/consumption by plugins
• Configuration Locality
  • Don't read/parse strings at the top of files for config detail (too much can go wrong and it's kind of confusing) - come up with a standard plugin config file that can be imported to necessary plugin functions
• Connectivity
  • Plugins should inherit connectivity; try to keep any connection specific details out of plugins, aside from checking for connectivity (there may be some exceptions; if so, come up with a standard on how to handle in the plugin 'config file'

Should Support (try)

• Filtering - Offer the ability to filter based on common elements, such as:
  • Datacenter
  • Cluster
  • VMHost
  • Datastore
  • VM name containing a certain string value
  • SRM placeholder VMs
• Support for multiple endpoints
• Improved Performance
  • Try to parallelize execution of plugins
• Credential Management
  • Consistent means of storing credentials
• Tests
  • Utilize Pester tests to validate plugins - subsequently require modules to pass standard tests before allowing PRs to be accepted, etc.
  • Add Pester tests for module and functions

Assumptions

Contraints

• Execution is performed within a single foreach loop
• Report generation is somewhat complex in order to account for dynamic creation of sections, etc. - involves quite a bit of looping