The current code expects "uname -W" on AIX to always succeed. The AIX 5
instance I have doesn't support the -W flag and facts gathering always
crashes on it.
This skips some WPAR handling code if "uname -W" doesn't work.
- swapinfo on FreeBSD 6 (maybe 7 too?) doesn't support the "-m" flag for
fetching amounts in megabytes. This patch fetches amounts in kilobytes
and divides by 1024 (and also returns the result as an int instead of
a string).
- When no swap is configured, swapinfo prints a header line and nothing
else:
$ swapinfo
Device 1K-blocks Used Avail Capacity
The old version unexpectedly parsed that header line and emitted
nonsense values like:
"ansible_swapfree_mb": "Avail"
"ansible_swaptotal_mb": "1K-blocks"
This version emits those items altogether.
Since we use domain and account data to filter the project, listall is not needed and can return the wrong identical named project of another account if root admin permissions are used.
Fixed projects names are not case insensitive.
We're being too strict - there is a third possibility, which is that a
user will have defined the OS_* environment variables and expect them to
pass through.
There is a common pattern in modules where some parameters are required
only if another parameter is present AND set to a particular value. For
instance, if a cloud server state is "present" it's important to
indicate the image to be used, but if it's "absent", the image that was
used to launch it is not necessary. Provide a check that takes as an
input a list of 3-element tuples containing parameter to depend on, the
value it should be set to, and a list of parameters which are required
if the required parameter is set to the required value.
With this fix, we get a friendly error message:
failed: [localhost] => {"failed": true}
msg: value of argument start_port is not of type int and we were unable to automatically convert
With this fix, we get a friendly error message:
failed: [localhost] => {"failed": true}
msg: value of argument start_port is not of type int and we were unable to automatically convert
We're being too strict - there is a third possibility, which is that a
user will have defined the OS_* environment variables and expect them to
pass through.
