VMware: New module vmware_host_dns

[ckotte]

SUMMARY

vmware_host_dns is a drop-in replacement for the old module vmware_dns_config.

Rather than removing one module, and introducing a new module, we are replacing the old module with a compatible new module, but we are deprecating some of the original parameters instead. End goal is to not break existing playbooks and get rid of some parameters.

Compared to the other module, this module..:

• configures DNS on default TCP/IP stack in host.config.network.netStackInstance instead of deprecated host.configManager.networkSystem.dnsConfig
• enables configuration of DNS via DHCP or static
• enables verbose message for DNS server changes
  e.g. "msg": "DNS server '10.168.1.10' added and '10.168.1.11' removed and the server sequence changed as well"
• enables configuration of search domains
• supports check mode
• supports esxi_hostname and cluster_name options
• uses the same naming convention as the other vmware_host modules

ISSUE TYPE

• New Module Pull Request

COMPONENT NAME

vmware_host_dns

ANSIBLE VERSION

ansible 2.6.3
  config file = /root/ansible-vmware/ansible.cfg
  configured module search path = [u'/root/ansible-vmware/library']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.5 (default, Jul 13 2018, 13:06:57) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]

ADDITIONAL INFORMATION

[ansibot]

Hi @ckotte, thank you for submitting this pull-request!

click here for bot help

[ansibot]

cc @Akasurde @dav1x @warthog9
click here for bot help

[ansibot]

@ckotte, just so you are aware we have a dedicated Working Group for vmware.
You can find other people interested in this in #ansible-vmware on Freenode IRC
For more information about communities, meetings and agendas see https://github.com/ansible/community

click here for bot help

[ckotte]

@dagwieers @Akasurde I didn't want to update the "old" module vmware_dns_config because there were so many changes necessary anyway. How could we remove the old module since two modules with the same scope doesn't make sense?

[dagwieers]

We cannot simply remove a module, we need to follow a deprecation process. This means that users will be notified that the module may disappear in 4 versions from now.

Another option is that we make the new module a drop-in replacement for the old one, by adding the parameters as aliases (or ghost parameters) so that they work exactly as before. In this case these ghost parameters or aliases could provide a deprecation-warning to the user so they have the time to modify their playbooks to the new design. (In this case we simply rename the old module to the new, so that the old name keeps on working as well)

[ckotte]

@dagwieers

We cannot simply remove a module, we need to follow a deprecation process. This means that users will be notified that the module may disappear in 4 versions from now.

Ok. I removed the old module, created a link, and some ghost parameters. Someone would just need to remove the code from the module and the symlink in 2.11, right?

[dagwieers]

Yes, every time there's a new release, the code is being reviewed for deprecated stuff and cleaned up. That's why it's good to add a # NOTE: The below block is also deprecated starting from Ansible v2.11

[dagwieers]

@ckotte I don't see the aliases (or ghost parameters) for:

• change_hostname_to
• domainname

Also search_domains is now required, which will break any existing tasks not having this.
Which means your new module is not a drop-in replacement :-/

[pdellaert]

Great module, but have some questions on differences between module definition and documentation

[pdellaert]

shouldn't the deprecated old change_hostname_to and domainname be mentioned as well? (i don't know the best protocol for ghost parameters)

[pdellaert]

Probably good to add ['type', 'dhcp', ['device']]?

[pdellaert]

These required parameters seem not required if i look at the module definition in the code? Only if the type is static? Probably best to update documentation accordingly for host_name, domain, dns_servers and search_domains. Will probably require some changes in the ensure method as well

Or if they are required, the module definition should be updated.

[ansibot]

cc @lparkes
click here for bot help

[ansibot]

cc @Tomorrow9
click here for bot help

[ansibot]

cc @goneri
click here for bot help

[goneri]

Hi,

We recently did a refactoring of the functional test-suite, the goal is to be able to run it on a regular VMware environment, this instead of vcsim.
As a consequence, you should not handle vcsim in the functional test anymore, use the prepare_vmware_roles role instead. e.g: https://github.com/ansible/ansible/blob/devel/test/integration/targets/vmware_drs_group/tasks/main.yml

You should also ensure the resources that are created during your test are properly removed at the end.

[ansibot]

cc @pgbidkar
click here for bot help

[mariolenz]

@ckotte I've cloned your feature branch and opened another PR: #64458

[Akasurde]

superseded by #64458. Thanks @ckotte for contribution.