community.vmware icon indicating copy to clipboard operation
community.vmware copied to clipboard

vmware_dvs_portgroup The number of ports cannot be configured when port allocation is set to 'elastic'

Open lingfish opened this issue 3 years ago • 9 comments

SUMMARY

When using this:

    num_ports: 8
    port_binding: static
    port_allocation: elastic

The module says:

msg: The number of ports cannot be configured when port allocation is set to 'elastic'.

I believe you can have both elastic and specify ports, as the UI lets me do that.

ISSUE TYPE
  • Bug Report
COMPONENT NAME

vmware.vmware_dvs_portgroup

ANSIBLE VERSION
  config file = /home/x/ansible/ansible.cfg
  configured module search path = ['/home/x/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/x/.virtualenvs/ansible-new/lib/python3.9/site-packages/ansible
  ansible collection location = /home/x/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/x/.virtualenvs/ansible-new/bin/ansible
  python version = 3.9.6 (default, Jul 30 2021, 12:15:58) [GCC 6.3.0 20170516]
  jinja version = 3.0.3
  libyaml = True
COLLECTION VERSION
---------------- -------
community.vmware 1.15.0
CONFIGURATION
DEFAULT_GATHERING(/home/x/ansible/ansible.cfg) = smart
DEFAULT_HOST_LIST(/home/x/ansible/ansible.cfg) = ['/home/x/ansible/inventory']
DEFAULT_LOAD_CALLBACK_PLUGINS(/home/x/ansible/ansible.cfg) = True
DEFAULT_STDOUT_CALLBACK(/home/x/ansible/ansible.cfg) = yaml
RETRY_FILES_ENABLED(/home/x/ansible/ansible.cfg) = True
OS / ENVIRONMENT

Debian GNU/Linux 9.6 (stretch)

STEPS TO REPRODUCE

As above.

EXPECTED RESULTS

Allow to set ports with elastic.

ACTUAL RESULTS

msg: The number of ports cannot be configured when port allocation is set to 'elastic'.

lingfish avatar Nov 23 '21 22:11 lingfish

I believe you can have both elastic and specify ports, as the UI lets me do that.

What vSphere version are you running? We're on 7.0U2something and I'm quite sure the UI doesn't allow setting the number of ports if you choose elastic port allocation.

Anyway, I don't understand why you even want to do this. If you want exactly 8 ports, use port_allocation: fixed. If you define port_allocation: elastic, you want vCenter to automatically increase or decrease the number of ports as needed. So why define num_ports at all in this case?

Not to put too fine a point on this, but this looks like an issue asking to implement something because it's possible and not because there's a real need or use case. I think you should either close this issue or give us a better reason to fix it than just "because it's possible".

mariolenz avatar Nov 29 '21 19:11 mariolenz

What vSphere version are you running?

I'm running 6.7.0 Build 18485185. I'm quite sure this version allows it, because I just did it.

Anyway, I don't understand why you even want to do this

I don't. I have upgraded from 2.9 to 2.11.6, and with over 186 DV PGs, I'm seeing changes all of a sudden where I didn't previously.

Your module isn't idempotent it would seem for me now, and diff mode isn't all that helpful in working out what specifically the module thinks it needs to change. I've had to gather facts, start doing three-way diffs, etc.

I'm stabbing in the dark at it, trying to figure out what to put in the play that would make it think no changes are needed, because there shouldn't be. One of those few stabs was elastic, but with a different port count.

Similar issue also at the end of https://github.com/ansible-collections/community.vmware/issues/1071#issuecomment-977246152

give us a better reason to fix it than just "because it's possible".

Hopefully this clears it up. I don't want to, but I'm trying to work out why all my DVs all of a sudden need changes when they clearly don't.

lingfish avatar Nov 29 '21 23:11 lingfish

    num_ports: 8
    port_binding: static
    port_allocation: elastic

The module says:

msg: The number of ports cannot be configured when port allocation is set to 'elastic'.

I believe you can have both elastic and specify ports, as the UI lets me do that.

I'm trying to fix this. Would it be possible for you to test PR #1150?

mariolenz avatar Dec 09 '21 15:12 mariolenz

I'm trying to fix this. Would it be possible for you to test PR #1150?

Sure. I've not ventured into the world of ansible-test though, and I note it mentions integration; will running these tests actually touch real (read: production) kit?

Would instead bringing in your PR and using --diff --test suffice?

lingfish avatar Dec 15 '21 05:12 lingfish

@lingfish You don't have to run ansible-test. It will run the complete test suite, but won't tell me anything about your special issue.

With test I meant: Clone the collection, get the PR (git fetch origin pull/1150/head:vmware_dvs_portgroup-portgroup_type && git checkout vmware_dvs_portgroup-portgroup_type) and use the task from your playbook to test if the module now behaves as expected.

I've tested this and I think it does now, but your mileage may vary ;-)

mariolenz avatar Dec 15 '21 05:12 mariolenz

@mariolenz thanks. I've gone back to what I was using config-wise for a dv, and I'm still seeing changes (even without port count).

The --diff output isn't helpful. I've used a combo of --check and vmware_dvs_portgroup_info to diff, nothing illuminating there other than a few nulls (which I would think should be fine).

Other than now creating another test dv, letting it change the dv, and grabbing the ugly output of what changed within vSphere logs to work out what the module thinks it should have changed, I'm at a loss re next steps.

lingfish avatar Dec 15 '21 07:12 lingfish

Ok, I think I've nailed it down to a few things... on a dv that shouldn't have changed, I see this in vSphere:

 config.defaultPortConfig.uplinkTeamingPolicy.uplinkPortOrder.inherited: true -> false;
 config.defaultPortConfig.macManagementPolicy.inherited: true -> false;
 config.defaultPortConfig.macManagementPolicy.allowPromiscuous: <unset> -> false;
 config.defaultPortConfig.macManagementPolicy.macChanges: <unset> -> true;
 config.defaultPortConfig.macManagementPolicy.forgedTransmits: <unset> -> true;

I've never seen defaultPortConfig before, and it doesn't seem to be a thing in the UI. According to this, it is "Common network setting for all the ports in the portgroup", and that link also suggests it is not a required property.

lingfish avatar Dec 16 '21 05:12 lingfish

Thanks for investigating, this helps a lot!

I'm not sure yet about this:

 config.defaultPortConfig.uplinkTeamingPolicy.uplinkPortOrder.inherited: true -> false;

I'll have to have a closer look at this. However, I think I can explain this:

 config.defaultPortConfig.macManagementPolicy.inherited: true -> false;
 config.defaultPortConfig.macManagementPolicy.allowPromiscuous: <unset> -> false;
 config.defaultPortConfig.macManagementPolicy.macChanges: <unset> -> true;
 config.defaultPortConfig.macManagementPolicy.forgedTransmits: <unset> -> true;

I don't know since when exactly, but the module has defaults for allowPromiscuous, macChanges and forgedTransmits for some time. But they've used to be configured in securityPolicy which has been deprecated by VMware. The module now uses macManagementPolicy (DVSMacManagementPolicy). I guess this is why you see a change.

So the module does what it did before, but you see a change because the vSphere API works differently now.

I've never seen defaultPortConfig before, and it doesn't seem to be a thing in the UI. According to this, it is "Common network setting for all the ports in the portgroup", and that link also suggests it is not a required property.

I think you're right, if you create a port group in the UI the default is to inherit from the DVS. Having a default for allowPromiscuous, macChanges and forgedTransmits in this module means we can't do this. I think we should change this.

However, this has nothing to do with the issue that the number of ports cannot be configured when port allocation is set to elastic. I think I've fixed this in #1150.

mariolenz avatar Dec 25 '21 17:12 mariolenz

@lingfish Would it be possible for you to test this with a 2.x version of community.vmware? I hope it's fixed there.

mariolenz avatar Mar 15 '22 15:03 mariolenz

I'm quite sure this has been fixed in version 2, so I'll close this for now. If you still run into this issue with 2.x, feel free to re-open it or open a new one.

mariolenz avatar Sep 29 '22 16:09 mariolenz