RFC: New parameters/modules for compliance/idempotentcy for Win

Archives Ansible Developer
1

Hi all,

Before embarking on developing changes to some existing Win modules and creating new modules for some specific idempotent handling it’d be good to get some comments on the following. Some items numbered for referenceability.

Background
One of my company’s key 3rd-party software suppliers delivers .msi packages. They are not good at reliably updating the imbeded ProductVersion and nor do they reliably update FileVersion for .exe/.dll files.
We’re in the process of building 80+ roles across 10 or so server types. These systems have many administrator/operations people that have varying perspectives on the importance of controlled deployments/configuration management.
We are wanting to implement compliance checking via Ansible. Additionally, since we have a design that combines deployment of a software component AND it’s configuration in the one role, we are wanting reliable idempotentcy
(component software and configuration can change independently)

Module Changes
In summary we’re looking to add creates_path/creates_filehash to a number of modules, as well as some other changes, and develop new supporting modules

  • win_package

  • creates_displayversion (was https://github.com/ansible/ansible/pull/42468)

  • creates_displayname (as above)

  • creates_filehash (would be hashcode result of Get-FileHash for file/folder specified in creates_path - default to MD5 algorithm - see https://gist.github.com/straff/796003e87132a466a8cf996eacff80b0)

  • win_unzip

  • creates_filehash (as above - for file specified in creates)

  • win_command/win_shell - as per win_unzip

  • win_get_url

  • creates or creates_path

  • creates_filehash (as above)
    the idea here is not to download large installers (e.g. Ora 12c client at 1.2GB) given already installed

New modules

Considerations

  1. is there a better place than this forum for discussing this ?
  2. develop this as a single PR, or one for each of win_package, unzip, command, shell, get_url and one to cover both new win_filehash and win_displayversion ?
  3. much of this can be achieved with tasks running win_command/shell and subsequent ‘when:’ logic, and in the case of win_get_url, it’s always followed by some other tasks - these could be in a block with ‘when:’, but
    that approach seems second-class compared to above ideas
  4. likely to develop the above even if only some or none gets back into official Ansible
  5. could avoid supporting folders for the hash function
  6. use MD5 only to keep it simple rather than have an ‘algorithm’ parameter

Regards, Straff

2
  • win_get_url
  • creates or creates_path
  • creates_filehash (as above)
    the idea here is not to download large installers (e.g. Ora 12c client at 1.2GB) given already installed

creates or creates_path would be redundant, since you’re already specifying a dest. The interface would preferably match get_url: checksum specifies the expected checksum and algorithm, the file isn’t downloaded if dest already exists and has that checksum unless force is specified, if the downloaded file has a different checksum the module errors.

New modules

  • win_filehash
  • path - path to file for Get-FileHash
  • algorithm - as per Get-FileHash - default to MD5

This is unnecessary; win_stat already supports getting the file hash.

3

Thanks … didn’t realise win_stat does hash so that’s good - win_filehash redundant
Re win_get_url dest is about the file being downloaded which would require that file to be kept
What I was intending was not to download the file based on an aspect of the install that that downloaded file was used for - presumably it will have created a path/file(s)
But maybe it’s not worth the effort here since there is a reasonable way to make idempotent via dest/keeping the original downloaded file