-
Notifications
You must be signed in to change notification settings - Fork 45
VSS Support #148
Comments
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:
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.
|
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" ***@***.***> wrote:
Thanks for taking a look at this! Adding the awesome compare link
<master...BrandonLundt:Issue148>
from your current branch. 😃
Speaking from the standpoint of just reviewing the diffs:
1. That structure looks pretty good, yeah
2. New-VesterConfig, line 160ish:
1. Get-VirtualSwitch is in the core module, so it doesn't need the
same check as Get-VDSwitch
2. I'll wait for your new issue to discuss the Get-VDSwitch check
there, instead of polluting the discussion here 🙂
3. 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
<#148 (comment)>,
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 |
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:
Seems like a good start and hopefully will give something to kick around while we figure out scope. |
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
vss
to$config.scope
in New-VesterConfig.\Tests\Network
to.\Tests\VDS
, and then add VSSContext
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.
The text was updated successfully, but these errors were encountered: