New os_server and os_server_actions modules

Hey Guys,

I was testing out the os_server and os_server_actions modules when I noticed that the start and stop actions were not included. I know the pull request said that the os_server_actions module was an initial commit with simple actions, but I added start and stop without any effort really so I was curious if there was another reason like compatibility issues or something like that?

In testing my additions to the os_server_actions module I found a couple of weird things that I would like others opinions of.

  1. Within the _wait function, a call is made to shade._iterate_timeout, but I was getting the following error:

`

TASK [test power off] ***********************************************************
ESTABLISH LOCAL CONNECTION FOR USER: centos
localhost EXEC mkdir -p $HOME/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459 && echo $HOME/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459
localhost PUT /tmp/tmp_Urb2i TO /root/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459/os_server_actions
localhost EXEC LANG=C LC_MESSAGES=C LC_CTYPE=C /usr/local/bin/python /root/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459/os_server_actions; rm -rf /root/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459/ >/dev/null 2>&1
An exception occurred during task execution. The full traceback is:
Traceback (most recent call last):
File “/root/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459/os_server_actions”, line 1942, in
main()
File “/root/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459/os_server_actions”, line 149, in main
_wait(timeout, cloud, server, action)
File “/root/.ansible/tmp/ansible-tmp-1435285563.72-8255955998459/os_server_actions”, line 93, in _wait
for count in shade._iterate_timeout(
AttributeError: ‘module’ object has no attribute ‘_iterate_timeout’

fatal: [os-test]: FAILED! => {“invocation”: {“module_name”: “os_server_actions”, “module_args”: {“action”: “stop”, “server”: “os-test”}}, “failed”: true, “changed”: false, “parsed”: false}

`

After looking at the shade source code, it just looks like that call should be shade._utils._iterate_timeout. So a diff looks like:

`

def _wait(timeout, cloud, server, action):
“”“Wait for the server to reach the desired state for the given action.”“”

  • for count in shade._iterate_timeout(
  • for count in shade._utils._iterate_timeout(

`

I just pip installed shade (as of today June 25th 2015). Is this a version issue or just a typo?

  1. The os_server module fails if the VM is not in the ACTIVE state. To me this check seems too restrictive, since if a VM is in the SHUTOFF state it’s still present and not in an error state. I updated the check to look for any of the states that exist in the os_server_actions module.

`

— a/cloud/openstack/os_server.py
+++ b/cloud/openstack/os_server.py
@@ -363,7 +363,7 @@ def _get_server_state(module, cloud):
state = module.params[‘state’]
server = cloud.get_server(module.params[‘name’])
if server and state == ‘present’:

  • if server.status != ‘ACTIVE’:
  • if server.status not in (‘ACTIVE’, ‘SHUTOFF’, ‘PAUSED’, ‘SUSPENDED’):
    module.fail_json(
    msg="The instance is available but not Active state: "
  • server.status)

`

Does anybody disagree with this?

  1. Theres this variable called _admin_actions which every action is in. The variable is used to decide whether to create an operator_cloud object or a openstack_cloud object. I’m not really sure why I would choose the operator_cloud. From the docstring it looks like that would be for admin only actions, but I don’t see any server actions as being something that only an admin would do. Should the stop and start actions be added to the admin_actions variable?

I appreciate the feedback. You can view my diff at https://github.com/tkinz27/ansible-modules-core/commit/d6779c1e6ac6af8bfdb1ddcdac0f84e52a2928f8 . If things are cool I can submit a pull request.

Thanks,
Tony

1. it is a bug either way, if it is version dependent it should be
stated as a requirement or detected and dealt with w/o a Exception.
2. sounds like a bug, but I would have to consult the author on this one.
3. also punting to author here, might be a placeholder.