# RFC: New parameters/modules for compliance/idempotentcy for Win **URL:** \ **Category:** Ansible Developer\ **Created:** [January 15, 2019, 8:27pm UTC](https://forum.ansible.com/t/rfc-new-parameters-modules-for-compliance-idempotentcy-for-win/29445 "2019-01-15T20:27:55Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![goforawalktwice](https://avatars.discourse-cdn.com/v4/letter/g/c5a1d2/32.png) [@goforawalktwice](https://forum.ansible.com/u/goforawalktwice)\ **Post date:** [January 15, 2019, 8:27pm UTC](https://forum.ansible.com/t/rfc-new-parameters-modules-for-compliance-idempotentcy-for-win/29445/1 "2019-01-15T20:27:55Z")
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](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](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** - win\_filehash - path - path to file for Get-FileHash - algorithm - as per Get-FileHash - default to MD5 - win\_displayversion - displayname - partial name of installed software as per Programs/Features - ref [https://gist.github.com/straff/ba3630a39ef9e1450f7e8bdd3bfb0b32](https://gist.github.com/straff/ba3630a39ef9e1450f7e8bdd3bfb0b32) **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 ---
**Author:** ![flowerysong1](https://avatars.discourse-cdn.com/v4/letter/f/ecae2f/32.png) [@flowerysong1](https://forum.ansible.com/u/flowerysong1)\ **Post date:** [January 15, 2019, 9:58pm UTC](https://forum.ansible.com/t/rfc-new-parameters-modules-for-compliance-idempotentcy-for-win/29445/2 "2019-01-15T21:58:53Z")
> - 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. ---
**Author:** ![goforawalktwice](https://avatars.discourse-cdn.com/v4/letter/g/c5a1d2/32.png) [@goforawalktwice](https://forum.ansible.com/u/goforawalktwice)\ **Post date:** [January 15, 2019, 11:41pm UTC](https://forum.ansible.com/t/rfc-new-parameters-modules-for-compliance-idempotentcy-for-win/29445/3 "2019-01-15T23:41:24Z")
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