powershell debug with complex_args list

Hi,

I was trying to debug and understand how ansible handles what it is in the yml and how it is transformed in powershell.

I came up with this test example where I have this structure

add_children:

  • beer:
    name: Ansible Brew
    type: light

It is hard for me to debug it and I wanted to execute the ps1 module outside of ansible as in https://docs.ansible.com/ansible/2.4/dev_guide/developing_modules_general_windows.html#windows-debugging using the complex_args structure

$complex_args = @{
    "_ansible_check_mode" = $false
    "_ansible_diff" = $false
    "path" = "C:\temp"
    "state" = "present"
}

But I’m struggling to reproduce the add_children. I can only see that the ansible Get-AnsibleParams when the type is a “list” all it does is

Convert string type to real Powershell array

$value = $value.Split(“,”).Trim()

Any clue about how to create this yml complex list?

Yaml is easily converted to some sort of structure, you are mostly dealing with dicts or lists, so in your case you can set complex_args to;

`
$complex_args = @{
add_children = @(
@{
name = “Ansible Brew”
type = “light”
}
)
}

`

As you can see we are setting the key add_children which is a list of dictionary values. In Python a list is expressed in the form of @(“entry”, “another_entry”) while dictionaries are expressed in the form or @{key = “value”; key2 = “value2”}. You can mix and match all these but once you understand how to convert Ansible to lists and dicts you should be good.

Depending on your version of the Legacy module_utils, Get-AnsibleParams just tries to convert the input source to the one that is expected, for a list, it will convert a string by splitting it by , but for existing lists it should just return that value as is.

Thanks

Jordan

Thanks for your insights @Jordan,

still I wasn’t able to reproduce the structure to work when debugging PS modules outside of ansible. I came up with a solution about using Export-Clixml, this is about executing the desired parameters and dumping them to disk as a PS xml object.

After all it can be re-loaded outside of Ansible context to understand how parameters are managed under the hood.

System.Management.Automation.PSCustomObject System.Object light Ansible Brew