vester
vester copied to clipboard
VSS Support
Vester currently only has tests for distributed switches in the Network folder. Standard switches should be supported.
Expected Behavior
Additional scope for VSS, to live side-by-side with VDS, ESXi, etc. Additional subfolder below .\Tests
to house all VSS-specific tests.
Current Behavior
No current VSS framework. VDS tests live in the "Network" folder; VDS/VSS should not live in the same folder.
Possible Solution
- Add
vss
to$config.scope
in New-VesterConfig - Add a VSS folder for Vester test files
- Rename
.\Tests\Network
to.\Tests\VDS
, and then add VSS- Keeping in mind that this is a minor breaking change
Context
VSS support was requested in chat today. The framework should allow for simple contribution of new Vester tests for VSS objects.
Any comments are welcome; with no feedback, I expect this to be implemented as described above.
Where you thinking along the lines of something like this for New-VesterConfig
And this for the tests
As before, I haven't tested this yet. :(
Thanks for taking a look at this! Adding the awesome compare link from your current branch. 😃
Speaking from the standpoint of just reviewing the diffs:
- That structure looks pretty good, yeah
-
New-VesterConfig
, line 160ish:-
Get-VirtualSwitch
is in the core module, so it doesn't need the same check asGet-VDSwitch
- I'll wait for your new issue to discuss the
Get-VDSwitch
check there, instead of polluting the discussion here 🙂
-
- VSS doesn't have the same feature set as VDS, so a lot of our VDS tests can't be copied into the VSS scope.
LinkDiscoveryProtocol
, for example
All in all, that's pretty much the structure change I had in mind! You could even submit with no VSS tests, and then that option is available for you or anybody else down the line.
~~I'm going to take the liberty of assigning you here, since you've already done most of the work.~~ (Apparently, I can only assign non-members to an issue if they created it?)
Would VSS tests fall under the 'Host' tests?
Side bar - could there potentially be a test to make sure all the hosts have the same portgroup configured? (You can disregard this if it is off topic).
On Oct 12, 2017 12:45 PM, "Brian Bunke" [email protected] wrote:
Thanks for taking a look at this! Adding the awesome compare link https://github.com/WahlNetwork/Vester/compare/master...BrandonLundt:Issue148 from your current branch. 😃
Speaking from the standpoint of just reviewing the diffs:
- That structure looks pretty good, yeah
- New-VesterConfig, line 160ish:
- Get-VirtualSwitch is in the core module, so it doesn't need the same check as Get-VDSwitch
- I'll wait for your new issue to discuss the Get-VDSwitch check there, instead of polluting the discussion here 🙂
- VSS doesn't have the same feature set as VDS, so a lot of our VDS tests can't be copied into the VSS scope. LinkDiscoveryProtocol, for example
All in all, that's pretty much the structure change I had in mind! You could even submit with no VSS tests, and then that option is available for you or anybody else down the line.
I'm going to take the liberty of assigning you here, since you've already done most of the work.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WahlNetwork/Vester/issues/148#issuecomment-336195938, or mute the thread https://github.com/notifications/unsubscribe-auth/ADxtkIPSBEEL6dnt4hod2W2uwY3f2VZGks5srkIhgaJpZM4NeYp- .
I thought the same thing when this issue first came up, and had to talk through it. If you have two standard switches on each host, the only way to enforce any differences between them is to add a VSS scope.
That test seems possible and useful, yeah.
Side note: Why does Get-VirtualSwitch
also return VDSwitches? Killing me. Need to filter those out when implementing this.
It would make sense to me that VSS values are scoped with the cluster. As conceivably each host in a cluster should have the same standard switch(and by extension port group). This would open up the ability to support VSS testing in a vCenter with multiple clusters. In our current setup, I feel like that is quite a jump and would rather walk into this instead of run.
What I would like to include in my next PR would be:
- The changes requested by @brianbunke for filtering Get-VirtualSwitch and updating the module load check in line 160-ish (This last one is already complete).
- Simple VSS tests.
Seems like a good start and hopefully will give something to kick around while we figure out scope.