Skip to content
This repository has been archived by the owner on Sep 4, 2020. It is now read-only.

VSS Support #148

Open
brianbunke opened this issue May 17, 2017 · 5 comments
Open

VSS Support #148

brianbunke opened this issue May 17, 2017 · 5 comments

Comments

@brianbunke
Copy link
Contributor

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.

@ghost
Copy link

ghost commented Oct 12, 2017

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. :(

@brianbunke
Copy link
Contributor Author

brianbunke commented Oct 12, 2017

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:

  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. (Apparently, I can only assign non-members to an issue if they created it?)

@midacts
Copy link
Contributor

midacts commented Oct 12, 2017 via email

@brianbunke
Copy link
Contributor Author

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.

@ghost
Copy link

ghost commented Oct 16, 2017

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:

  1. 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).
  2. Simple VSS tests.

Seems like a good start and hopefully will give something to kick around while we figure out scope.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants