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
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
/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 moduleShould Support (try)
Assumptions
Contraints
foreach
loop