# Dynamic types for module arguments

**URL:** <https://forum.ansible.com/t/dynamic-types-for-module-arguments/36194>\
**Category:** Ansible Project\
**Tags:** ansible-project\
**Created:** [January 12, 2022, 8:49pm UTC](https://forum.ansible.com/t/dynamic-types-for-module-arguments/36194 "2022-01-12T20:49:02Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [January 12, 2022, 8:49pm UTC](https://forum.ansible.com/t/dynamic-types-for-module-arguments/36194/1 "2022-01-12T20:49:02Z")

</div>

Hi Rhys,

> The original ssl\_cert\_reqs argument is a string. These string values  
> map to the new boolean values.
> 
> I basically want to map the strings as follows..
> 
> CERT\_NONE - True  
> CERT\_REQUIRED - False
> 
> But also allow boolean values to be accepted.

maybe doing `type: raw` with `choices: [CET\_NONE, CERT\_REQUIRED, true,  
false]` would work.

Alternatively, keep the old option, make the new and old option  
mutually\_exclusive, and eventually deprecate the old one. (While both  
exist, none can have a default, so you need to document the actual default  
manually in the documentation, and not with `default:`.)

I think having two separate options is probably the best way to handle  
this particularly strange one 🙂

Cheers,  
Felix