[PS-Module] Config & Config File handling

[vScripter]

Figure out the best way to handle global config, as well as plugin config.

Mind Map of Module Layout this is how the module is currently laid out.

Guidelines

• Simplicity - Make it as easy as possible to both run the report and develop a plugin
• Don't use numbers as a file prefix Like, never, 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/parsing 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'
• Filtering - Offer the ability to filter based on common elements, such as:
  • Datacenter
  • Cluster
  • VMHost
  • VM name containing a certain string value
• Support for multiple endpoints - I know this is a heavy request, but as I work through hacking things apart and tracing dependencies, I'm thinking if we can stick to some of the points, above, we might be able to specify multiple endpoints (vCenter Servers, NSX Managers, etc.) in the global config file and when you would execute Start-vCheck we might could drop right into a foreach loop, or even execute in different .NET runspaces to maximize parallel execution. (my brain is thinking some like a .JSON file that might look like the example, below (it's purely a spitball example):

Example Config File

[
    {
        "endpoint": [
            {
                "name": "vcenter01.example1.com",
                "ipv4address": "192.168.1.10",
                "type:": "vcenter",
                "connection": {
                    "credentialPath": "",
                    "region": "nyc.payload1",
                    "tenant": "Example 1",
                    "description": "NYC payload-1 vcenter server"
                },
                "inventory": {
                    "datacenter": "",
                    "cluster": "",
                    "vmhost": "",
                    "vm": ""
                }
            },
            {
                "name": "vcenter02.example2.com",
                "ipv4address": "192.168.1.11",
                "type:": "vcenter",
                "config": {
                    "credentialPath": "",
                    "region": "nyc.payload2",
                    "tenant": "Example 2",
                    "description": "NYC payload-2 vcenter server",
                    "inventory": {
                        "datacenter": "",
                        "cluster": "",
                        "vmhost": "",
                        "vm": ""
                    }
                }
            },
            {
                "name": "vnsxmgr01.example.com",
                "ipv4address": "192.168.1.12",
                "type:": "nsx",
                "config": {
                    "credentialPath": "",
                    "region": "nyc.payload1",
                    "tenant": "Example",
                    "description": "NYC payload-1 nsx manager"
                }
            }
        ]
    }
]

[Sneddo]

I guess we need to keep this fairly simple as well, to not create a barrier to stop people developing thier own plugins.

The variable values should also not be written back to the plugin like it is now, as it makes updating more difficult.

Once we come up with a solution to the plugins, I'd suggest we effectively merge globalVariables.ps1 into vCheck itself (and possibly handle EndScript.ps1 as well) in a similar manner.

[vScripter]

@Sneddo I completely agree 💯 ; my thoughts are almost right in line with everything you mentioned, trying to keep the following points, below, at the forefront. If you have a minute, check out the layout I put together, based on how I configured the initial module.

• Make it as easy as possible to develop a plugin
• Keep plugin configuration limited to the scope of the plugin/plugin functions
• Make it easier to understand (and consume) configurations (variables) that are globally available for use/consumption by plugins
• Move away from reading/parsing strings at the top of files (too much can go wrong and it's kind of confusing) - come up with a standard plugin config file that can be analyzed/imported
• 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'
• Support for multiple endpoints - I know this is a heavy request, but as I work through hacking things apart and tracing dependencies, I'm thinking if we can stick to some of the points, above, we might be able to specify multiple endpoints (vCenter Servers, NSX Managers, etc.) in the global config file and when you would execute Start-vCheck we might could drop right into a foreach loop, or even execute in different .NET runspaces to maximize parallel execution.

[davehocking]

Hi folks, great to see the behind-the-scenes discussions going on RE: development, I think (hope) that I'm going to learn a lot just by listening to you.

On the multiple end-points subject, it's something I thought about for the work on vCheck-NSX, if you could find a way to make it work, it would be really useful - I have multiple copies of the vCheck report running, which in some respects works well, as the two platforms I'm querying have different use cases - on one platform I don't care about VM-level checks, on the other I do - You'd possibly want some way of being able to tell each plugin which VC's you care about being checked against (and potentially different exclusions/variables for each too).

[Sneddo]

@vScripter Yeah, looking good 👍 I had a go at converting to modules a couple of years ago and just couldn't quite come up with a solution that worked well enough to persist with. I think we're on the right track though 😄

I'll throw another thing into the mix- filtering. This is something that has come up a lot over the years of vCheck. People want to be able to filter objects in reports e.g. just run a report against a single datacenter/cluster/host/whatever. Building in a standard filtering definition into our plugins (and ideally the connection/endpoint definition) would be a nice feature.

[vScripter]

@Sneddo That's a good one 👌🏻

[vScripter]

Added the summarized list to the description of this issue as well as an updated config file with some different samples of what we might could use (global config).

[mrkwbr]

just throwing this out there -
it seems to me that there were be a lot of benefit to making the vCheck framework its own module and then each project module could include it as a dependency.
each project could then focus on writing checks - plus fixes to the framework would be available to all projects without having to update each individually.

are there technical issues with separating out the framework in that way?

thanks
mark

[vScripter]

@mrkwbr I'm actually working on getting that functionality in place, however, it's pretty close to an entire re-write of the tool, in order to support the original functionality and fix some of the other limitations the existing framework has. The way I am approaching it, each test framework will be a 'Plugin', which will basically be a directory with the test files beneath it. There is a link to the module layout in the issue description, above, that I am keeping up to date as I work through the re-design.