2014-11-14 22:14:08 +00:00
|
|
|
# (c) 2013-2014, Michael DeHaan <michael.dehaan@gmail.com>
|
2015-02-10 20:35:34 +00:00
|
|
|
# (c) 2015 Toshio Kuratomi <tkuratomi@ansible.com>
|
2014-11-14 22:14:08 +00:00
|
|
|
#
|
|
|
|
# This file is part of Ansible
|
|
|
|
#
|
|
|
|
# Ansible is free software: you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation, either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# Ansible is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with Ansible. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
2015-02-10 20:35:34 +00:00
|
|
|
# Make coding more python3-ish
|
|
|
|
from __future__ import (absolute_import, division, print_function)
|
|
|
|
__metaclass__ = type
|
|
|
|
|
2016-04-05 23:33:56 +00:00
|
|
|
import ast
|
2016-04-05 18:06:17 +00:00
|
|
|
import base64
|
2016-11-29 09:21:13 +00:00
|
|
|
import datetime
|
2016-04-19 07:55:19 +00:00
|
|
|
import imp
|
2014-11-14 22:14:08 +00:00
|
|
|
import json
|
|
|
|
import os
|
|
|
|
import shlex
|
2016-04-05 18:06:17 +00:00
|
|
|
import zipfile
|
2017-02-17 08:09:56 +00:00
|
|
|
import re
|
2016-04-05 18:06:17 +00:00
|
|
|
from io import BytesIO
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2016-04-29 00:36:09 +00:00
|
|
|
from ansible.release import __version__, __author__
|
2014-11-14 22:14:08 +00:00
|
|
|
from ansible import constants as C
|
|
|
|
from ansible.errors import AnsibleError
|
2018-10-02 22:55:53 +00:00
|
|
|
from ansible.executor.powershell import module_manifest as ps_manifest
|
2018-02-22 02:03:16 +00:00
|
|
|
from ansible.module_utils._text import to_bytes, to_text, to_native
|
2018-10-02 22:55:53 +00:00
|
|
|
from ansible.plugins.loader import module_utils_loader
|
2016-04-30 03:47:51 +00:00
|
|
|
# Must import strategy and use write_locks from there
|
|
|
|
# If we import write_locks directly then we end up binding a
|
|
|
|
# variable to the object and then it never gets updated.
|
2016-08-26 19:55:56 +00:00
|
|
|
from ansible.executor import action_write_locks
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2018-11-20 23:06:51 +00:00
|
|
|
from ansible.utils.display import Display
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2018-11-20 23:06:51 +00:00
|
|
|
display = Display()
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2017-05-30 17:13:53 +00:00
|
|
|
REPLACER = b"#<<INCLUDE_ANSIBLE_MODULE_COMMON>>"
|
|
|
|
REPLACER_VERSION = b"\"<<ANSIBLE_VERSION>>\""
|
|
|
|
REPLACER_COMPLEX = b"\"<<INCLUDE_ANSIBLE_MODULE_COMPLEX_ARGS>>\""
|
|
|
|
REPLACER_WINDOWS = b"# POWERSHELL_COMMON"
|
2016-02-27 00:41:13 +00:00
|
|
|
REPLACER_JSONARGS = b"<<INCLUDE_ANSIBLE_MODULE_JSON_ARGS>>"
|
2017-05-30 17:13:53 +00:00
|
|
|
REPLACER_SELINUX = b"<<SELINUX_SPECIAL_FILESYSTEMS>>"
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2015-02-10 20:35:34 +00:00
|
|
|
# We could end up writing out parameters with unicode characters so we need to
|
|
|
|
# specify an encoding for the python source file
|
2016-04-06 07:23:47 +00:00
|
|
|
ENCODING_STRING = u'# -*- coding: utf-8 -*-'
|
2018-02-22 02:03:16 +00:00
|
|
|
b_ENCODING_STRING = b'# -*- coding: utf-8 -*-'
|
2015-02-10 20:35:34 +00:00
|
|
|
|
2017-01-27 19:53:02 +00:00
|
|
|
# module_common is relative to module_utils, so fix the path
|
|
|
|
_MODULE_UTILS_PATH = os.path.join(os.path.dirname(__file__), '..', 'module_utils')
|
2015-02-10 20:35:34 +00:00
|
|
|
|
|
|
|
# ******************************************************************************
|
|
|
|
|
2016-07-21 17:58:24 +00:00
|
|
|
ANSIBALLZ_TEMPLATE = u'''%(shebang)s
|
2016-04-06 07:23:47 +00:00
|
|
|
%(coding)s
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
_ANSIBALLZ_WRAPPER = True # For test-module script to tell this is a ANSIBALLZ_WRAPPER
|
2016-04-07 04:37:04 +00:00
|
|
|
# This code is part of Ansible, but is an independent component.
|
|
|
|
# The code in this particular templatable string, and this templatable string
|
|
|
|
# only, is BSD licensed. Modules which end up using this snippet, which is
|
|
|
|
# dynamically combined together by Ansible still belong to the author of the
|
|
|
|
# module, and they may assign their own license to the complete work.
|
|
|
|
#
|
|
|
|
# Copyright (c), James Cammarata, 2016
|
|
|
|
# Copyright (c), Toshio Kuratomi, 2016
|
|
|
|
#
|
|
|
|
# Redistribution and use in source and binary forms, with or without modification,
|
|
|
|
# are permitted provided that the following conditions are met:
|
|
|
|
#
|
|
|
|
# * Redistributions of source code must retain the above copyright
|
|
|
|
# notice, this list of conditions and the following disclaimer.
|
|
|
|
# * Redistributions in binary form must reproduce the above copyright notice,
|
|
|
|
# this list of conditions and the following disclaimer in the documentation
|
|
|
|
# and/or other materials provided with the distribution.
|
|
|
|
#
|
|
|
|
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
|
|
|
|
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
|
|
|
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
# IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
|
|
|
|
# USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
def _ansiballz_main():
|
|
|
|
import os
|
|
|
|
import os.path
|
|
|
|
import sys
|
|
|
|
import __main__
|
|
|
|
|
|
|
|
# For some distros and python versions we pick up this script in the temporary
|
|
|
|
# directory. This leads to problems when the ansible module masks a python
|
|
|
|
# library that another import needs. We have not figured out what about the
|
|
|
|
# specific distros and python versions causes this to behave differently.
|
|
|
|
#
|
|
|
|
# Tested distros:
|
|
|
|
# Fedora23 with python3.4 Works
|
|
|
|
# Ubuntu15.10 with python2.7 Works
|
|
|
|
# Ubuntu15.10 with python3.4 Fails without this
|
|
|
|
# Ubuntu16.04.1 with python3.5 Fails without this
|
|
|
|
# To test on another platform:
|
|
|
|
# * use the copy module (since this shadows the stdlib copy module)
|
|
|
|
# * Turn off pipelining
|
|
|
|
# * Make sure that the destination file does not exist
|
|
|
|
# * ansible ubuntu16-test -m copy -a 'src=/etc/motd dest=/var/tmp/m'
|
|
|
|
# This will traceback in shutil. Looking at the complete traceback will show
|
|
|
|
# that shutil is importing copy which finds the ansible module instead of the
|
|
|
|
# stdlib module
|
|
|
|
scriptdir = None
|
|
|
|
try:
|
|
|
|
scriptdir = os.path.dirname(os.path.realpath(__main__.__file__))
|
|
|
|
except (AttributeError, OSError):
|
|
|
|
# Some platforms don't set __file__ when reading from stdin
|
|
|
|
# OSX raises OSError if using abspath() in a directory we don't have
|
|
|
|
# permission to read (realpath calls abspath)
|
|
|
|
pass
|
|
|
|
if scriptdir is not None:
|
|
|
|
sys.path = [p for p in sys.path if p != scriptdir]
|
|
|
|
|
|
|
|
import base64
|
2018-07-15 01:30:02 +00:00
|
|
|
import imp
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
import shutil
|
|
|
|
import tempfile
|
|
|
|
import zipfile
|
|
|
|
|
|
|
|
if sys.version_info < (3,):
|
|
|
|
bytes = str
|
2018-07-15 01:30:02 +00:00
|
|
|
MOD_DESC = ('.py', 'U', imp.PY_SOURCE)
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
PY3 = False
|
|
|
|
else:
|
|
|
|
unicode = str
|
2018-07-15 01:30:02 +00:00
|
|
|
MOD_DESC = ('.py', 'r', imp.PY_SOURCE)
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
PY3 = True
|
|
|
|
|
|
|
|
ZIPDATA = """%(zipdata)s"""
|
|
|
|
|
2018-07-15 01:30:02 +00:00
|
|
|
# Note: temp_path isn't needed once we switch to zipimport
|
|
|
|
def invoke_module(modlib_path, temp_path, json_params):
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
# When installed via setuptools (including python setup.py install),
|
|
|
|
# ansible may be installed with an easy-install.pth file. That file
|
|
|
|
# may load the system-wide install of ansible rather than the one in
|
|
|
|
# the module. sitecustomize is the only way to override that setting.
|
|
|
|
z = zipfile.ZipFile(modlib_path, mode='a')
|
|
|
|
|
|
|
|
# py3: modlib_path will be text, py2: it's bytes. Need bytes at the end
|
|
|
|
sitecustomize = u'import sys\\nsys.path.insert(0,"%%s")\\n' %% modlib_path
|
|
|
|
sitecustomize = sitecustomize.encode('utf-8')
|
|
|
|
# Use a ZipInfo to work around zipfile limitation on hosts with
|
|
|
|
# clocks set to a pre-1980 year (for instance, Raspberry Pi)
|
|
|
|
zinfo = zipfile.ZipInfo()
|
|
|
|
zinfo.filename = 'sitecustomize.py'
|
|
|
|
zinfo.date_time = ( %(year)i, %(month)i, %(day)i, %(hour)i, %(minute)i, %(second)i)
|
|
|
|
z.writestr(zinfo, sitecustomize)
|
2018-07-15 01:30:02 +00:00
|
|
|
# Note: Remove the following section when we switch to zipimport
|
|
|
|
# Write the module to disk for imp.load_module
|
|
|
|
module = os.path.join(temp_path, '__main__.py')
|
|
|
|
with open(module, 'wb') as f:
|
|
|
|
f.write(z.read('__main__.py'))
|
|
|
|
f.close()
|
|
|
|
# End pre-zipimport section
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
z.close()
|
|
|
|
|
|
|
|
# Put the zipped up module_utils we got from the controller first in the python path so that we
|
|
|
|
# can monkeypatch the right basic
|
|
|
|
sys.path.insert(0, modlib_path)
|
|
|
|
|
|
|
|
# Monkeypatch the parameters into basic
|
|
|
|
from ansible.module_utils import basic
|
|
|
|
basic._ANSIBLE_ARGS = json_params
|
|
|
|
%(coverage)s
|
|
|
|
# Run the module! By importing it as '__main__', it thinks it is executing as a script
|
2018-07-15 01:30:02 +00:00
|
|
|
with open(module, 'rb') as mod:
|
|
|
|
imp.load_module('__main__', mod, module, MOD_DESC)
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
|
|
|
|
# Ansible modules must exit themselves
|
|
|
|
print('{"msg": "New-style module did not handle its own exit", "failed": true}')
|
|
|
|
sys.exit(1)
|
2016-08-24 07:43:50 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
def debug(command, zipped_mod, json_params):
|
|
|
|
# The code here normally doesn't run. It's only used for debugging on the
|
|
|
|
# remote machine.
|
|
|
|
#
|
|
|
|
# The subcommands in this function make it easier to debug ansiballz
|
|
|
|
# modules. Here's the basic steps:
|
|
|
|
#
|
|
|
|
# Run ansible with the environment variable: ANSIBLE_KEEP_REMOTE_FILES=1 and -vvv
|
|
|
|
# to save the module file remotely::
|
|
|
|
# $ ANSIBLE_KEEP_REMOTE_FILES=1 ansible host1 -m ping -a 'data=october' -vvv
|
|
|
|
#
|
|
|
|
# Part of the verbose output will tell you where on the remote machine the
|
|
|
|
# module was written to::
|
|
|
|
# [...]
|
|
|
|
# <host1> SSH: EXEC ssh -C -q -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o
|
|
|
|
# PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 -o
|
|
|
|
# ControlPath=/home/badger/.ansible/cp/ansible-ssh-%%h-%%p-%%r -tt rhel7 '/bin/sh -c '"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8
|
|
|
|
# LC_MESSAGES=en_US.UTF-8 /usr/bin/python /home/badger/.ansible/tmp/ansible-tmp-1461173013.93-9076457629738/ping'"'"''
|
|
|
|
# [...]
|
|
|
|
#
|
|
|
|
# Login to the remote machine and run the module file via from the previous
|
|
|
|
# step with the explode subcommand to extract the module payload into
|
|
|
|
# source files::
|
|
|
|
# $ ssh host1
|
|
|
|
# $ /usr/bin/python /home/badger/.ansible/tmp/ansible-tmp-1461173013.93-9076457629738/ping explode
|
|
|
|
# Module expanded into:
|
|
|
|
# /home/badger/.ansible/tmp/ansible-tmp-1461173408.08-279692652635227/ansible
|
|
|
|
#
|
|
|
|
# You can now edit the source files to instrument the code or experiment with
|
|
|
|
# different parameter values. When you're ready to run the code you've modified
|
|
|
|
# (instead of the code from the actual zipped module), use the execute subcommand like this::
|
|
|
|
# $ /usr/bin/python /home/badger/.ansible/tmp/ansible-tmp-1461173013.93-9076457629738/ping execute
|
|
|
|
|
|
|
|
# Okay to use __file__ here because we're running from a kept file
|
|
|
|
basedir = os.path.join(os.path.abspath(os.path.dirname(__file__)), 'debug_dir')
|
|
|
|
args_path = os.path.join(basedir, 'args')
|
|
|
|
script_path = os.path.join(basedir, '__main__.py')
|
|
|
|
|
|
|
|
if command == 'excommunicate':
|
|
|
|
print('The excommunicate debug command is deprecated and will be removed in 2.11. Use execute instead.')
|
|
|
|
command = 'execute'
|
|
|
|
|
|
|
|
if command == 'explode':
|
|
|
|
# transform the ZIPDATA into an exploded directory of code and then
|
|
|
|
# print the path to the code. This is an easy way for people to look
|
|
|
|
# at the code on the remote machine for debugging it in that
|
|
|
|
# environment
|
|
|
|
z = zipfile.ZipFile(zipped_mod)
|
|
|
|
for filename in z.namelist():
|
|
|
|
if filename.startswith('/'):
|
|
|
|
raise Exception('Something wrong with this module zip file: should not contain absolute paths')
|
|
|
|
|
|
|
|
dest_filename = os.path.join(basedir, filename)
|
|
|
|
if dest_filename.endswith(os.path.sep) and not os.path.exists(dest_filename):
|
|
|
|
os.makedirs(dest_filename)
|
|
|
|
else:
|
|
|
|
directory = os.path.dirname(dest_filename)
|
|
|
|
if not os.path.exists(directory):
|
|
|
|
os.makedirs(directory)
|
|
|
|
f = open(dest_filename, 'wb')
|
|
|
|
f.write(z.read(filename))
|
|
|
|
f.close()
|
|
|
|
|
|
|
|
# write the args file
|
|
|
|
f = open(args_path, 'wb')
|
|
|
|
f.write(json_params)
|
|
|
|
f.close()
|
2016-04-07 04:25:18 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
print('Module expanded into:')
|
|
|
|
print('%%s' %% basedir)
|
|
|
|
exitcode = 0
|
2016-04-10 19:33:16 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
elif command == 'execute':
|
|
|
|
# Execute the exploded code instead of executing the module from the
|
|
|
|
# embedded ZIPDATA. This allows people to easily run their modified
|
|
|
|
# code on the remote machine to see how changes will affect it.
|
2016-04-05 18:06:17 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
# Set pythonpath to the debug dir
|
|
|
|
sys.path.insert(0, basedir)
|
2016-04-10 19:33:16 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
# read in the args file which the user may have modified
|
|
|
|
with open(args_path, 'rb') as f:
|
|
|
|
json_params = f.read()
|
2016-04-10 19:33:16 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
# Monkeypatch the parameters into basic
|
|
|
|
from ansible.module_utils import basic
|
|
|
|
basic._ANSIBLE_ARGS = json_params
|
|
|
|
|
|
|
|
# Run the module! By importing it as '__main__', it thinks it is executing as a script
|
|
|
|
import imp
|
|
|
|
with open(script_path, 'r') as f:
|
|
|
|
importer = imp.load_module('__main__', f, script_path, ('.py', 'r', imp.PY_SOURCE))
|
|
|
|
|
|
|
|
# Ansible modules must exit themselves
|
|
|
|
print('{"msg": "New-style module did not handle its own exit", "failed": true}')
|
|
|
|
sys.exit(1)
|
2016-04-10 19:33:16 +00:00
|
|
|
|
2016-04-14 16:06:38 +00:00
|
|
|
else:
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
print('WARNING: Unknown debug command. Doing nothing.')
|
|
|
|
exitcode = 0
|
2016-04-05 18:06:17 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
return exitcode
|
2016-04-10 19:33:16 +00:00
|
|
|
|
2016-04-20 17:34:57 +00:00
|
|
|
#
|
|
|
|
# See comments in the debug() method for information on debugging
|
|
|
|
#
|
|
|
|
|
2016-07-21 17:58:24 +00:00
|
|
|
ANSIBALLZ_PARAMS = %(params)s
|
2016-04-12 17:08:00 +00:00
|
|
|
if PY3:
|
2016-07-21 17:58:24 +00:00
|
|
|
ANSIBALLZ_PARAMS = ANSIBALLZ_PARAMS.encode('utf-8')
|
2016-04-05 18:06:17 +00:00
|
|
|
try:
|
2016-04-22 22:55:13 +00:00
|
|
|
# There's a race condition with the controller removing the
|
|
|
|
# remote_tmpdir and this module executing under async. So we cannot
|
|
|
|
# store this in remote_tmpdir (use system tempdir instead)
|
2018-07-15 01:30:02 +00:00
|
|
|
# Only need to use [ansible_module]_payload_ in the temp_path until we move to zipimport
|
|
|
|
# (this helps ansible-test produce coverage stats)
|
|
|
|
temp_path = tempfile.mkdtemp(prefix='ansible_%(ansible_module)s_payload_')
|
2016-06-13 14:56:18 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
zipped_mod = os.path.join(temp_path, 'ansible_%(ansible_module)s_payload.zip')
|
|
|
|
with open(zipped_mod, 'wb') as modlib:
|
|
|
|
modlib.write(base64.b64decode(ZIPDATA))
|
2016-06-13 14:56:18 +00:00
|
|
|
|
2016-04-10 19:33:16 +00:00
|
|
|
if len(sys.argv) == 2:
|
2016-07-21 17:58:24 +00:00
|
|
|
exitcode = debug(sys.argv[1], zipped_mod, ANSIBALLZ_PARAMS)
|
2016-04-10 19:33:16 +00:00
|
|
|
else:
|
2018-07-15 01:30:02 +00:00
|
|
|
# Note: temp_path isn't needed once we switch to zipimport
|
|
|
|
invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)
|
2016-04-10 19:33:16 +00:00
|
|
|
finally:
|
|
|
|
try:
|
2016-04-11 04:14:53 +00:00
|
|
|
shutil.rmtree(temp_path)
|
2017-06-06 14:59:50 +00:00
|
|
|
except (NameError, OSError):
|
2016-04-11 04:14:53 +00:00
|
|
|
# tempdir creation probably failed
|
2016-04-10 19:33:16 +00:00
|
|
|
pass
|
|
|
|
sys.exit(exitcode)
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
|
|
|
|
if __name__ == '__main__':
|
|
|
|
_ansiballz_main()
|
|
|
|
'''
|
|
|
|
|
|
|
|
ANSIBALLZ_COVERAGE_TEMPLATE = '''
|
|
|
|
# Access to the working directory is required by coverage.
|
|
|
|
# Some platforms, such as macOS, may not allow querying the working directory when using become to drop privileges.
|
|
|
|
try:
|
|
|
|
os.getcwd()
|
|
|
|
except OSError:
|
|
|
|
os.chdir('/')
|
|
|
|
|
|
|
|
os.environ['COVERAGE_FILE'] = '%(coverage_output)s'
|
|
|
|
|
|
|
|
import atexit
|
|
|
|
import coverage
|
|
|
|
|
|
|
|
cov = coverage.Coverage(config_file='%(coverage_config)s')
|
|
|
|
|
|
|
|
def atexit_coverage():
|
|
|
|
cov.stop()
|
|
|
|
cov.save()
|
|
|
|
|
|
|
|
atexit.register(atexit_coverage)
|
|
|
|
|
|
|
|
cov.start()
|
2016-04-05 18:06:17 +00:00
|
|
|
'''
|
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2016-04-20 17:34:57 +00:00
|
|
|
def _strip_comments(source):
|
|
|
|
# Strip comments and blank lines from the wrapper
|
|
|
|
buf = []
|
|
|
|
for line in source.splitlines():
|
|
|
|
l = line.strip()
|
|
|
|
if not l or l.startswith(u'#'):
|
|
|
|
continue
|
|
|
|
buf.append(line)
|
|
|
|
return u'\n'.join(buf)
|
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2016-04-20 17:34:57 +00:00
|
|
|
if C.DEFAULT_KEEP_REMOTE_FILES:
|
|
|
|
# Keep comments when KEEP_REMOTE_FILES is set. That way users will see
|
|
|
|
# the comments with some nice usage instructions
|
2016-07-21 17:58:24 +00:00
|
|
|
ACTIVE_ANSIBALLZ_TEMPLATE = ANSIBALLZ_TEMPLATE
|
2016-04-20 17:34:57 +00:00
|
|
|
else:
|
2016-07-21 17:58:24 +00:00
|
|
|
# ANSIBALLZ_TEMPLATE stripped of comments for smaller over the wire size
|
|
|
|
ACTIVE_ANSIBALLZ_TEMPLATE = _strip_comments(ANSIBALLZ_TEMPLATE)
|
2016-04-20 17:34:57 +00:00
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2016-04-05 23:33:56 +00:00
|
|
|
class ModuleDepFinder(ast.NodeVisitor):
|
|
|
|
# Caveats:
|
|
|
|
# This code currently does not handle:
|
|
|
|
# * relative imports from py2.6+ from . import urls
|
|
|
|
IMPORT_PREFIX_SIZE = len('ansible.module_utils.')
|
|
|
|
|
|
|
|
def __init__(self, *args, **kwargs):
|
2016-04-19 07:55:19 +00:00
|
|
|
"""
|
|
|
|
Walk the ast tree for the python module.
|
|
|
|
|
|
|
|
Save submodule[.submoduleN][.identifier] into self.submodules
|
|
|
|
|
|
|
|
self.submodules will end up with tuples like:
|
|
|
|
- ('basic',)
|
|
|
|
- ('urls', 'fetch_url')
|
|
|
|
- ('database', 'postgres')
|
|
|
|
- ('database', 'postgres', 'quote')
|
|
|
|
|
|
|
|
It's up to calling code to determine whether the final element of the
|
|
|
|
dotted strings are module names or something else (function, class, or
|
|
|
|
variable names)
|
|
|
|
"""
|
2016-04-05 23:33:56 +00:00
|
|
|
super(ModuleDepFinder, self).__init__(*args, **kwargs)
|
2016-04-19 07:55:19 +00:00
|
|
|
self.submodules = set()
|
2016-04-05 23:33:56 +00:00
|
|
|
|
|
|
|
def visit_Import(self, node):
|
2016-04-19 07:55:19 +00:00
|
|
|
# import ansible.module_utils.MODLIB[.MODLIBn] [as asname]
|
2016-04-05 23:33:56 +00:00
|
|
|
for alias in (a for a in node.names if a.name.startswith('ansible.module_utils.')):
|
2016-04-19 07:55:19 +00:00
|
|
|
py_mod = alias.name[self.IMPORT_PREFIX_SIZE:]
|
2016-06-04 23:19:57 +00:00
|
|
|
py_mod = tuple(py_mod.split('.'))
|
|
|
|
self.submodules.add(py_mod)
|
2016-04-05 23:33:56 +00:00
|
|
|
self.generic_visit(node)
|
|
|
|
|
|
|
|
def visit_ImportFrom(self, node):
|
2017-03-23 20:35:05 +00:00
|
|
|
# Specialcase: six is a special case because of its
|
|
|
|
# import logic
|
|
|
|
if node.names[0].name == '_six':
|
|
|
|
self.submodules.add(('_six',))
|
|
|
|
elif node.module.startswith('ansible.module_utils'):
|
2016-04-05 23:33:56 +00:00
|
|
|
where_from = node.module[self.IMPORT_PREFIX_SIZE:]
|
|
|
|
if where_from:
|
2016-04-19 07:55:19 +00:00
|
|
|
# from ansible.module_utils.MODULE1[.MODULEn] import IDENTIFIER [as asname]
|
|
|
|
# from ansible.module_utils.MODULE1[.MODULEn] import MODULEn+1 [as asname]
|
|
|
|
# from ansible.module_utils.MODULE1[.MODULEn] import MODULEn+1 [,IDENTIFIER] [as asname]
|
|
|
|
py_mod = tuple(where_from.split('.'))
|
|
|
|
for alias in node.names:
|
|
|
|
self.submodules.add(py_mod + (alias.name,))
|
2016-04-05 23:33:56 +00:00
|
|
|
else:
|
2016-04-19 07:55:19 +00:00
|
|
|
# from ansible.module_utils import MODLIB [,MODLIB2] [as asname]
|
2016-04-05 23:33:56 +00:00
|
|
|
for alias in node.names:
|
2016-04-19 07:55:19 +00:00
|
|
|
self.submodules.add((alias.name,))
|
2016-04-05 23:33:56 +00:00
|
|
|
self.generic_visit(node)
|
|
|
|
|
|
|
|
|
2015-02-10 20:35:34 +00:00
|
|
|
def _slurp(path):
|
|
|
|
if not os.path.exists(path):
|
2016-04-19 07:55:19 +00:00
|
|
|
raise AnsibleError("imported module support code does not exist at %s" % os.path.abspath(path))
|
2016-02-27 00:41:13 +00:00
|
|
|
fd = open(path, 'rb')
|
2015-02-10 20:35:34 +00:00
|
|
|
data = fd.read()
|
|
|
|
fd.close()
|
|
|
|
return data
|
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2017-12-08 14:59:24 +00:00
|
|
|
def _get_shebang(interpreter, task_vars, templar, args=tuple()):
|
2016-04-05 18:06:17 +00:00
|
|
|
"""
|
|
|
|
Note not stellar API:
|
|
|
|
Returns None instead of always returning a shebang line. Doing it this
|
|
|
|
way allows the caller to decide to use the shebang it read from the
|
|
|
|
file rather than trust that we reformatted what they already have
|
|
|
|
correctly.
|
|
|
|
"""
|
2016-04-28 03:11:26 +00:00
|
|
|
interpreter_config = u'ansible_%s_interpreter' % os.path.basename(interpreter).strip()
|
2016-04-05 18:06:17 +00:00
|
|
|
|
|
|
|
if interpreter_config not in task_vars:
|
2016-04-07 04:25:18 +00:00
|
|
|
return (None, interpreter)
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2017-12-08 14:59:24 +00:00
|
|
|
interpreter = templar.template(task_vars[interpreter_config].strip())
|
2016-04-05 18:06:17 +00:00
|
|
|
shebang = u'#!' + interpreter
|
|
|
|
|
|
|
|
if args:
|
|
|
|
shebang = shebang + u' ' + u' '.join(args)
|
|
|
|
|
2016-04-07 04:25:18 +00:00
|
|
|
return (shebang, interpreter)
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2016-04-19 07:55:19 +00:00
|
|
|
def recursive_finder(name, data, py_module_names, py_module_cache, zf):
|
2016-04-06 06:48:37 +00:00
|
|
|
"""
|
|
|
|
Using ModuleDepFinder, make sure we have all of the module_utils files that
|
|
|
|
the module its module_utils files needs.
|
|
|
|
"""
|
2016-04-19 07:55:19 +00:00
|
|
|
# Parse the module and find the imports of ansible.module_utils
|
2019-01-04 05:03:37 +00:00
|
|
|
try:
|
|
|
|
tree = ast.parse(data)
|
|
|
|
except (SyntaxError, IndentationError) as e:
|
|
|
|
raise AnsibleError("Unable to import %s due to %s" % (name, e.msg))
|
2016-04-05 23:33:56 +00:00
|
|
|
finder = ModuleDepFinder()
|
|
|
|
finder.visit(tree)
|
|
|
|
|
2016-04-19 07:55:19 +00:00
|
|
|
#
|
|
|
|
# Determine what imports that we've found are modules (vs class, function.
|
|
|
|
# variable names) for packages
|
|
|
|
#
|
|
|
|
|
|
|
|
normalized_modules = set()
|
|
|
|
# Loop through the imports that we've found to normalize them
|
|
|
|
# Exclude paths that match with paths we've already processed
|
|
|
|
# (Have to exclude them a second time once the paths are processed)
|
2017-01-27 19:53:02 +00:00
|
|
|
|
|
|
|
module_utils_paths = [p for p in module_utils_loader._get_paths(subdirs=False) if os.path.isdir(p)]
|
|
|
|
module_utils_paths.append(_MODULE_UTILS_PATH)
|
2016-04-19 07:55:19 +00:00
|
|
|
for py_module_name in finder.submodules.difference(py_module_names):
|
|
|
|
module_info = None
|
2016-06-04 23:19:57 +00:00
|
|
|
|
|
|
|
if py_module_name[0] == 'six':
|
|
|
|
# Special case the python six library because it messes up the
|
|
|
|
# import process in an incompatible way
|
2017-01-27 19:53:02 +00:00
|
|
|
module_info = imp.find_module('six', module_utils_paths)
|
2016-06-04 23:19:57 +00:00
|
|
|
py_module_name = ('six',)
|
|
|
|
idx = 0
|
2017-03-23 20:35:05 +00:00
|
|
|
elif py_module_name[0] == '_six':
|
|
|
|
# Special case the python six library because it messes up the
|
|
|
|
# import process in an incompatible way
|
|
|
|
module_info = imp.find_module('_six', [os.path.join(p, 'six') for p in module_utils_paths])
|
|
|
|
py_module_name = ('six', '_six')
|
|
|
|
idx = 0
|
2016-06-04 23:19:57 +00:00
|
|
|
else:
|
|
|
|
# Check whether either the last or the second to last identifier is
|
|
|
|
# a module name
|
|
|
|
for idx in (1, 2):
|
|
|
|
if len(py_module_name) < idx:
|
|
|
|
break
|
|
|
|
try:
|
|
|
|
module_info = imp.find_module(py_module_name[-idx],
|
2017-05-30 17:13:53 +00:00
|
|
|
[os.path.join(p, *py_module_name[:-idx]) for p in module_utils_paths])
|
2016-06-04 23:19:57 +00:00
|
|
|
break
|
|
|
|
except ImportError:
|
|
|
|
continue
|
2016-04-05 23:33:56 +00:00
|
|
|
|
2016-04-19 07:55:19 +00:00
|
|
|
# Could not find the module. Construct a helpful error message.
|
|
|
|
if module_info is None:
|
2017-03-23 20:35:05 +00:00
|
|
|
msg = ['Could not find imported module support code for %s. Looked for' % (name,)]
|
2016-04-19 07:55:19 +00:00
|
|
|
if idx == 2:
|
2017-02-03 01:48:53 +00:00
|
|
|
msg.append('either %s.py or %s.py' % (py_module_name[-1], py_module_name[-2]))
|
|
|
|
else:
|
|
|
|
msg.append(py_module_name[-1])
|
|
|
|
raise AnsibleError(' '.join(msg))
|
|
|
|
|
|
|
|
# Found a byte compiled file rather than source. We cannot send byte
|
|
|
|
# compiled over the wire as the python version might be different.
|
|
|
|
# imp.find_module seems to prefer to return source packages so we just
|
|
|
|
# error out if imp.find_module returns byte compiled files (This is
|
|
|
|
# fragile as it depends on undocumented imp.find_module behaviour)
|
|
|
|
if module_info[2][2] not in (imp.PY_SOURCE, imp.PKG_DIRECTORY):
|
|
|
|
msg = ['Could not find python source for imported module support code for %s. Looked for' % name]
|
|
|
|
if idx == 2:
|
|
|
|
msg.append('either %s.py or %s.py' % (py_module_name[-1], py_module_name[-2]))
|
2016-04-19 07:55:19 +00:00
|
|
|
else:
|
|
|
|
msg.append(py_module_name[-1])
|
|
|
|
raise AnsibleError(' '.join(msg))
|
|
|
|
|
|
|
|
if idx == 2:
|
|
|
|
# We've determined that the last portion was an identifier and
|
|
|
|
# thus, not part of the module name
|
|
|
|
py_module_name = py_module_name[:-1]
|
|
|
|
|
|
|
|
# If not already processed then we've got work to do
|
2018-08-24 06:24:39 +00:00
|
|
|
# If not in the cache, then read the file into the cache
|
|
|
|
# We already have a file handle for the module open so it makes
|
|
|
|
# sense to read it now
|
|
|
|
if py_module_name not in py_module_cache:
|
|
|
|
if module_info[2][2] == imp.PKG_DIRECTORY:
|
|
|
|
# Read the __init__.py instead of the module file as this is
|
|
|
|
# a python package
|
|
|
|
normalized_name = py_module_name + ('__init__',)
|
|
|
|
if normalized_name not in py_module_names:
|
2017-04-17 20:04:40 +00:00
|
|
|
normalized_path = os.path.join(os.path.join(module_info[1], '__init__.py'))
|
|
|
|
normalized_data = _slurp(normalized_path)
|
2018-08-24 06:24:39 +00:00
|
|
|
py_module_cache[normalized_name] = (normalized_data, normalized_path)
|
|
|
|
normalized_modules.add(normalized_name)
|
|
|
|
else:
|
|
|
|
normalized_name = py_module_name
|
|
|
|
if normalized_name not in py_module_names:
|
2017-04-17 20:04:40 +00:00
|
|
|
normalized_path = module_info[1]
|
|
|
|
normalized_data = module_info[0].read()
|
2016-04-19 07:55:19 +00:00
|
|
|
module_info[0].close()
|
2018-08-24 06:24:39 +00:00
|
|
|
py_module_cache[normalized_name] = (normalized_data, normalized_path)
|
|
|
|
normalized_modules.add(normalized_name)
|
2016-04-19 07:55:19 +00:00
|
|
|
|
|
|
|
# Make sure that all the packages that this module is a part of
|
|
|
|
# are also added
|
|
|
|
for i in range(1, len(py_module_name)):
|
|
|
|
py_pkg_name = py_module_name[:-i] + ('__init__',)
|
|
|
|
if py_pkg_name not in py_module_names:
|
2017-01-27 19:53:02 +00:00
|
|
|
pkg_dir_info = imp.find_module(py_pkg_name[-1],
|
2017-05-30 17:13:53 +00:00
|
|
|
[os.path.join(p, *py_pkg_name[:-1]) for p in module_utils_paths])
|
2016-04-19 07:55:19 +00:00
|
|
|
normalized_modules.add(py_pkg_name)
|
2017-04-17 20:04:40 +00:00
|
|
|
py_module_cache[py_pkg_name] = (_slurp(pkg_dir_info[1]), pkg_dir_info[1])
|
2016-04-19 07:55:19 +00:00
|
|
|
|
2018-08-23 01:18:01 +00:00
|
|
|
# FIXME: Currently the AnsiBallZ wrapper monkeypatches module args into a global
|
|
|
|
# variable in basic.py. If a module doesn't import basic.py, then the AnsiBallZ wrapper will
|
|
|
|
# traceback when it tries to monkypatch. So, for now, we have to unconditionally include
|
|
|
|
# basic.py.
|
|
|
|
#
|
|
|
|
# In the future we need to change the wrapper to monkeypatch the args into a global variable in
|
|
|
|
# their own, separate python module. That way we won't require basic.py. Modules which don't
|
|
|
|
# want basic.py can import that instead. AnsibleModule will need to change to import the vars
|
|
|
|
# from the separate python module and mirror the args into its global variable for backwards
|
|
|
|
# compatibility.
|
|
|
|
if ('basic',) not in py_module_names:
|
|
|
|
pkg_dir_info = imp.find_module('basic', module_utils_paths)
|
|
|
|
normalized_modules.add(('basic',))
|
|
|
|
py_module_cache[('basic',)] = (_slurp(pkg_dir_info[1]), pkg_dir_info[1])
|
|
|
|
# End of AnsiballZ hack
|
|
|
|
|
2016-04-19 07:55:19 +00:00
|
|
|
#
|
|
|
|
# iterate through all of the ansible.module_utils* imports that we haven't
|
|
|
|
# already checked for new imports
|
|
|
|
#
|
|
|
|
|
|
|
|
# set of modules that we haven't added to the zipfile
|
|
|
|
unprocessed_py_module_names = normalized_modules.difference(py_module_names)
|
|
|
|
|
|
|
|
for py_module_name in unprocessed_py_module_names:
|
|
|
|
py_module_path = os.path.join(*py_module_name)
|
|
|
|
py_module_file_name = '%s.py' % py_module_path
|
|
|
|
|
|
|
|
zf.writestr(os.path.join("ansible/module_utils",
|
2017-05-30 17:13:53 +00:00
|
|
|
py_module_file_name), py_module_cache[py_module_name][0])
|
2017-08-15 20:38:59 +00:00
|
|
|
display.vvvvv("Using module_utils file %s" % py_module_cache[py_module_name][1])
|
2016-04-19 07:55:19 +00:00
|
|
|
|
|
|
|
# Add the names of the files we're scheduling to examine in the loop to
|
|
|
|
# py_module_names so that we don't re-examine them in the next pass
|
|
|
|
# through recursive_finder()
|
|
|
|
py_module_names.update(unprocessed_py_module_names)
|
|
|
|
|
|
|
|
for py_module_file in unprocessed_py_module_names:
|
2017-04-17 20:04:40 +00:00
|
|
|
recursive_finder(py_module_file, py_module_cache[py_module_file][0], py_module_names, py_module_cache, zf)
|
2016-04-19 07:55:19 +00:00
|
|
|
# Save memory; the file won't have to be read again for this ansible module.
|
|
|
|
del py_module_cache[py_module_file]
|
2016-04-05 23:33:56 +00:00
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2017-01-27 19:53:02 +00:00
|
|
|
def _is_binary(b_module_data):
|
2016-05-11 20:14:01 +00:00
|
|
|
textchars = bytearray(set([7, 8, 9, 10, 12, 13, 27]) | set(range(0x20, 0x100)) - set([0x7f]))
|
2017-01-27 19:53:02 +00:00
|
|
|
start = b_module_data[:1024]
|
2016-05-11 20:14:01 +00:00
|
|
|
return bool(start.translate(None, textchars))
|
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
|
2017-12-08 14:59:24 +00:00
|
|
|
def _find_module_utils(module_name, b_module_data, module_path, module_args, task_vars, templar, module_compression, async_timeout, become,
|
2018-01-19 21:58:10 +00:00
|
|
|
become_method, become_user, become_password, become_flags, environment):
|
2015-02-10 20:35:34 +00:00
|
|
|
"""
|
|
|
|
Given the source of the module, convert it to a Jinja2 template to insert
|
|
|
|
module code and return whether it's a new or old style module.
|
|
|
|
"""
|
2016-04-05 18:06:17 +00:00
|
|
|
module_substyle = module_style = 'old'
|
|
|
|
|
|
|
|
# module_style is something important to calling code (ActionBase). It
|
|
|
|
# determines how arguments are formatted (json vs k=v) and whether
|
|
|
|
# a separate arguments file needs to be sent over the wire.
|
|
|
|
# module_substyle is extra information that's useful internally. It tells
|
|
|
|
# us what we have to look to substitute in the module files and whether
|
2016-07-21 17:58:24 +00:00
|
|
|
# we're using module replacer or ansiballz to format the module itself.
|
2017-01-27 19:53:02 +00:00
|
|
|
if _is_binary(b_module_data):
|
2016-05-12 17:46:07 +00:00
|
|
|
module_substyle = module_style = 'binary'
|
2017-01-27 19:53:02 +00:00
|
|
|
elif REPLACER in b_module_data:
|
2016-04-05 18:06:17 +00:00
|
|
|
# Do REPLACER before from ansible.module_utils because we need make sure
|
|
|
|
# we substitute "from ansible.module_utils basic" for REPLACER
|
|
|
|
module_style = 'new'
|
|
|
|
module_substyle = 'python'
|
2017-01-27 19:53:02 +00:00
|
|
|
b_module_data = b_module_data.replace(REPLACER, b'from ansible.module_utils.basic import *')
|
|
|
|
elif b'from ansible.module_utils.' in b_module_data:
|
2015-02-10 20:35:34 +00:00
|
|
|
module_style = 'new'
|
2016-04-05 18:06:17 +00:00
|
|
|
module_substyle = 'python'
|
2017-10-23 21:21:30 +00:00
|
|
|
elif REPLACER_WINDOWS in b_module_data:
|
|
|
|
module_style = 'new'
|
|
|
|
module_substyle = 'powershell'
|
|
|
|
b_module_data = b_module_data.replace(REPLACER_WINDOWS, b'#Requires -Module Ansible.ModuleUtils.Legacy')
|
2017-11-21 03:08:30 +00:00
|
|
|
elif re.search(b'#Requires -Module', b_module_data, re.IGNORECASE) \
|
|
|
|
or re.search(b'#Requires -Version', b_module_data, re.IGNORECASE)\
|
2018-11-07 00:53:17 +00:00
|
|
|
or re.search(b'#AnsibleRequires -OSVersion', b_module_data, re.IGNORECASE) \
|
|
|
|
or re.search(b'#AnsibleRequires -CSharpUtil', b_module_data, re.IGNORECASE):
|
2015-07-24 16:39:54 +00:00
|
|
|
module_style = 'new'
|
2016-04-05 18:06:17 +00:00
|
|
|
module_substyle = 'powershell'
|
2017-01-27 19:53:02 +00:00
|
|
|
elif REPLACER_JSONARGS in b_module_data:
|
2015-09-07 03:01:26 +00:00
|
|
|
module_style = 'new'
|
2016-04-05 18:06:17 +00:00
|
|
|
module_substyle = 'jsonargs'
|
2017-01-27 19:53:02 +00:00
|
|
|
elif b'WANT_JSON' in b_module_data:
|
2016-04-05 18:06:17 +00:00
|
|
|
module_substyle = module_style = 'non_native_want_json'
|
|
|
|
|
|
|
|
shebang = None
|
2016-05-11 20:14:01 +00:00
|
|
|
# Neither old-style, non_native_want_json nor binary modules should be modified
|
2016-04-05 18:06:17 +00:00
|
|
|
# except for the shebang line (Done by modify_module)
|
2016-05-11 20:14:01 +00:00
|
|
|
if module_style in ('old', 'non_native_want_json', 'binary'):
|
2017-01-27 19:53:02 +00:00
|
|
|
return b_module_data, module_style, shebang
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2016-02-27 00:41:13 +00:00
|
|
|
output = BytesIO()
|
2016-04-19 07:55:19 +00:00
|
|
|
py_module_names = set()
|
2016-04-05 18:06:17 +00:00
|
|
|
|
|
|
|
if module_substyle == 'python':
|
2016-05-13 03:30:05 +00:00
|
|
|
params = dict(ANSIBLE_MODULE_ARGS=module_args,)
|
2016-06-04 23:19:57 +00:00
|
|
|
python_repred_params = repr(json.dumps(params))
|
2016-04-05 18:06:17 +00:00
|
|
|
|
|
|
|
try:
|
|
|
|
compression_method = getattr(zipfile, module_compression)
|
|
|
|
except AttributeError:
|
|
|
|
display.warning(u'Bad module compression string specified: %s. Using ZIP_STORED (no compression)' % module_compression)
|
|
|
|
compression_method = zipfile.ZIP_STORED
|
2016-04-06 06:48:37 +00:00
|
|
|
|
2016-07-21 17:58:24 +00:00
|
|
|
lookup_path = os.path.join(C.DEFAULT_LOCAL_TMP, 'ansiballz_cache')
|
2016-04-06 06:48:37 +00:00
|
|
|
cached_module_filename = os.path.join(lookup_path, "%s-%s" % (module_name, module_compression))
|
|
|
|
|
|
|
|
zipdata = None
|
|
|
|
# Optimization -- don't lock if the module has already been cached
|
|
|
|
if os.path.exists(cached_module_filename):
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: using cached module: %s' % cached_module_filename)
|
2018-10-09 22:53:03 +00:00
|
|
|
with open(cached_module_filename, 'rb') as module_data:
|
|
|
|
zipdata = module_data.read()
|
2016-04-06 06:48:37 +00:00
|
|
|
else:
|
2016-08-26 19:55:56 +00:00
|
|
|
if module_name in action_write_locks.action_write_locks:
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Using lock for %s' % module_name)
|
2016-08-26 19:55:56 +00:00
|
|
|
lock = action_write_locks.action_write_locks[module_name]
|
2016-04-30 03:47:51 +00:00
|
|
|
else:
|
|
|
|
# If the action plugin directly invokes the module (instead of
|
|
|
|
# going through a strategy) then we don't have a cross-process
|
|
|
|
# Lock specifically for this module. Use the "unexpected
|
|
|
|
# module" lock instead
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Using generic lock for %s' % module_name)
|
2016-08-26 19:55:56 +00:00
|
|
|
lock = action_write_locks.action_write_locks[None]
|
2016-04-30 03:47:51 +00:00
|
|
|
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Acquiring lock')
|
2016-04-30 03:47:51 +00:00
|
|
|
with lock:
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Lock acquired: %s' % id(lock))
|
2016-04-06 06:48:37 +00:00
|
|
|
# Check that no other process has created this while we were
|
|
|
|
# waiting for the lock
|
|
|
|
if not os.path.exists(cached_module_filename):
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Creating module')
|
2016-04-06 06:48:37 +00:00
|
|
|
# Create the module zip data
|
|
|
|
zipoutput = BytesIO()
|
|
|
|
zf = zipfile.ZipFile(zipoutput, mode='w', compression=compression_method)
|
2016-09-07 05:54:17 +00:00
|
|
|
# Note: If we need to import from release.py first,
|
|
|
|
# remember to catch all exceptions: https://github.com/ansible/ansible/issues/16523
|
|
|
|
zf.writestr('ansible/__init__.py',
|
2017-05-30 17:13:53 +00:00
|
|
|
b'from pkgutil import extend_path\n__path__=extend_path(__path__,__name__)\n__version__="' +
|
|
|
|
to_bytes(__version__) + b'"\n__author__="' +
|
|
|
|
to_bytes(__author__) + b'"\n')
|
2016-04-29 00:36:09 +00:00
|
|
|
zf.writestr('ansible/module_utils/__init__.py', b'from pkgutil import extend_path\n__path__=extend_path(__path__,__name__)\n')
|
2016-04-06 06:48:37 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
zf.writestr('__main__.py', b_module_data)
|
2016-04-06 06:48:37 +00:00
|
|
|
|
2017-05-30 17:13:53 +00:00
|
|
|
py_module_cache = {('__init__',): (b'', '[builtin]')}
|
2017-01-27 19:53:02 +00:00
|
|
|
recursive_finder(module_name, b_module_data, py_module_names, py_module_cache, zf)
|
2016-04-06 06:48:37 +00:00
|
|
|
zf.close()
|
|
|
|
zipdata = base64.b64encode(zipoutput.getvalue())
|
|
|
|
|
|
|
|
# Write the assembled module to a temp file (write to temp
|
|
|
|
# so that no one looking for the file reads a partially
|
|
|
|
# written file)
|
2016-04-18 18:51:45 +00:00
|
|
|
if not os.path.exists(lookup_path):
|
|
|
|
# Note -- if we have a global function to setup, that would
|
|
|
|
# be a better place to run this
|
2016-09-15 13:57:15 +00:00
|
|
|
os.makedirs(lookup_path)
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Writing module')
|
2016-06-04 23:19:57 +00:00
|
|
|
with open(cached_module_filename + '-part', 'wb') as f:
|
2016-04-06 06:48:37 +00:00
|
|
|
f.write(zipdata)
|
|
|
|
|
|
|
|
# Rename the file into its final position in the cache so
|
|
|
|
# future users of this module can read it off the
|
|
|
|
# filesystem instead of constructing from scratch.
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Renaming module')
|
2016-04-06 06:48:37 +00:00
|
|
|
os.rename(cached_module_filename + '-part', cached_module_filename)
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Done creating module')
|
2016-04-06 06:48:37 +00:00
|
|
|
|
|
|
|
if zipdata is None:
|
2016-07-21 17:58:24 +00:00
|
|
|
display.debug('ANSIBALLZ: Reading module after lock')
|
2016-04-06 06:48:37 +00:00
|
|
|
# Another process wrote the file while we were waiting for
|
|
|
|
# the write lock. Go ahead and read the data from disk
|
|
|
|
# instead of re-creating it.
|
2016-04-18 18:51:45 +00:00
|
|
|
try:
|
2019-01-11 15:14:08 +00:00
|
|
|
with open(cached_module_filename, 'rb') as f:
|
|
|
|
zipdata = f.read()
|
2016-04-18 18:51:45 +00:00
|
|
|
except IOError:
|
2017-05-30 17:13:53 +00:00
|
|
|
raise AnsibleError('A different worker process failed to create module file. '
|
|
|
|
'Look at traceback for that process for debugging information.')
|
2016-09-07 05:54:17 +00:00
|
|
|
zipdata = to_text(zipdata, errors='surrogate_or_strict')
|
2016-04-20 17:34:57 +00:00
|
|
|
|
2017-12-08 14:59:24 +00:00
|
|
|
shebang, interpreter = _get_shebang(u'/usr/bin/python', task_vars, templar)
|
2016-04-07 04:25:18 +00:00
|
|
|
if shebang is None:
|
|
|
|
shebang = u'#!/usr/bin/python'
|
2016-04-28 03:11:26 +00:00
|
|
|
|
2016-07-26 14:46:16 +00:00
|
|
|
# Enclose the parts of the interpreter in quotes because we're
|
|
|
|
# substituting it into the template as a Python string
|
|
|
|
interpreter_parts = interpreter.split(u' ')
|
|
|
|
interpreter = u"'{0}'".format(u"', '".join(interpreter_parts))
|
2016-04-28 03:11:26 +00:00
|
|
|
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
coverage_config = os.environ.get('_ANSIBLE_COVERAGE_CONFIG')
|
|
|
|
|
|
|
|
if coverage_config:
|
|
|
|
# Enable code coverage analysis of the module.
|
|
|
|
# This feature is for internal testing and may change without notice.
|
|
|
|
coverage = ANSIBALLZ_COVERAGE_TEMPLATE % dict(
|
|
|
|
coverage_config=coverage_config,
|
|
|
|
coverage_output=os.environ['_ANSIBLE_COVERAGE_OUTPUT']
|
|
|
|
)
|
|
|
|
else:
|
|
|
|
coverage = ''
|
|
|
|
|
2017-05-30 17:13:53 +00:00
|
|
|
now = datetime.datetime.utcnow()
|
2016-07-21 17:58:24 +00:00
|
|
|
output.write(to_bytes(ACTIVE_ANSIBALLZ_TEMPLATE % dict(
|
2016-04-06 06:48:37 +00:00
|
|
|
zipdata=zipdata,
|
2016-04-05 18:06:17 +00:00
|
|
|
ansible_module=module_name,
|
2016-04-10 19:33:16 +00:00
|
|
|
params=python_repred_params,
|
2016-04-05 18:06:17 +00:00
|
|
|
shebang=shebang,
|
2016-04-07 04:25:18 +00:00
|
|
|
interpreter=interpreter,
|
2016-04-06 07:23:47 +00:00
|
|
|
coding=ENCODING_STRING,
|
2016-11-29 09:21:13 +00:00
|
|
|
year=now.year,
|
|
|
|
month=now.month,
|
|
|
|
day=now.day,
|
|
|
|
hour=now.hour,
|
|
|
|
minute=now.minute,
|
|
|
|
second=now.second,
|
AnsiballZ improvements
Now that we don't need to worry about python-2.4 and 2.5, we can make
some improvements to the way AnsiballZ handles modules.
* Change AnsiballZ wrapper to use import to invoke the module
We need the module to think of itself as a script because it could be
coded as:
main()
or as:
if __name__ == '__main__':
main()
Or even as:
if __name__ == '__main__':
random_function_name()
A script will invoke all of those. Prior to this change, we invoked
a second Python interpreter on the module so that it really was
a script. However, this means that we have to run python twice (once
for the AnsiballZ wrapper and once for the module). This change makes
the module think that it is a script (because __name__ in the module ==
'__main__') but it's actually being invoked by us importing the module
code.
There's three ways we've come up to do this.
* The most elegant is to use zipimporter and tell the import mechanism
that the module being loaded is __main__:
* https://github.com/abadger/ansible/blob/5959f11c9ddb7b6eaa9c3214560bd85e631d4055/lib/ansible/executor/module_common.py#L175
* zipimporter is nice because we do not have to extract the module from
the zip file and save it to the disk when we do that. The import
machinery does it all for us.
* The drawback is that modules do not have a __file__ which points
to a real file when they do this. Modules could be using __file__
to for a variety of reasons, most of those probably have
replacements (the most common one is to find a writable directory
for temporary files. AnsibleModule.tmpdir should be used instead)
We can monkeypatch __file__ in fom AnsibleModule initialization
but that's kind of gross. There's no way I can see to do this
from the wrapper.
* Next, there's imp.load_module():
* https://github.com/abadger/ansible/blob/340edf7489/lib/ansible/executor/module_common.py#L151
* imp has the nice property of allowing us to set __name__ to
__main__ without changing the name of the file itself
* We also don't have to do anything special to set __file__ for
backwards compatibility (although the reason for that is the
drawback):
* Its drawback is that it requires the file to exist on disk so we
have to explicitly extract it from the zipfile and save it to
a temporary file
* The last choice is to use exec to execute the module:
* https://github.com/abadger/ansible/blob/f47a4ccc76/lib/ansible/executor/module_common.py#L175
* The code we would have to maintain for this looks pretty clean.
In the wrapper we create a ModuleType, set __file__ on it, read
the module's contents in from the zip file and then exec it.
* Drawbacks: We still have to explicitly extract the file's contents
from the zip archive instead of letting python's import mechanism
handle it.
* Exec also has hidden performance issues and breaks certain
assumptions that modules could be making about their own code:
http://lucumr.pocoo.org/2011/2/1/exec-in-python/
Our plan is to use imp.load_module() for now, deprecate the use of
__file__ in modules, and switch to zipimport once the deprecation
period for __file__ is over (without monkeypatching a fake __file__ in
via AnsibleModule).
* Rename the name of the AnsiBallZ wrapped module
This makes it obvious that the wrapped module isn't the module file that
we distribute. It's part of trying to mitigate the fact that the module
is now named __main)).py in tracebacks.
* Shield all wrapper symbols inside of a function
With the new import code, all symbols in the wrapper become visible in
the module. To mitigate the chance of collisions, move most symbols
into a toplevel function. The only symbols left in the global namespace
are now _ANSIBALLZ_WRAPPER and _ansiballz_main.
revised porting guide entry
Integrate code coverage collection into AnsiballZ.
ci_coverage
ci_complete
2018-06-20 18:23:59 +00:00
|
|
|
coverage=coverage,
|
2016-09-07 05:54:17 +00:00
|
|
|
)))
|
2017-01-27 19:53:02 +00:00
|
|
|
b_module_data = output.getvalue()
|
2016-04-05 18:06:17 +00:00
|
|
|
|
|
|
|
elif module_substyle == 'powershell':
|
2016-07-11 18:51:28 +00:00
|
|
|
# Powershell/winrm don't actually make use of shebang so we can
|
|
|
|
# safely set this here. If we let the fallback code handle this
|
|
|
|
# it can fail in the presence of the UTF8 BOM commonly added by
|
|
|
|
# Windows text editors
|
|
|
|
shebang = u'#!powershell'
|
2018-09-12 22:50:13 +00:00
|
|
|
# create the common exec wrapper payload and set that as the module_data
|
|
|
|
# bytes
|
2018-10-02 22:55:53 +00:00
|
|
|
b_module_data = ps_manifest._create_powershell_wrapper(
|
2018-09-12 22:50:13 +00:00
|
|
|
b_module_data, module_args, environment, async_timeout, become,
|
|
|
|
become_method, become_user, become_password, become_flags,
|
2018-10-02 22:55:53 +00:00
|
|
|
module_substyle
|
2017-06-27 05:58:09 +00:00
|
|
|
)
|
|
|
|
|
2016-04-05 18:06:17 +00:00
|
|
|
elif module_substyle == 'jsonargs':
|
2016-04-10 19:33:16 +00:00
|
|
|
module_args_json = to_bytes(json.dumps(module_args))
|
|
|
|
|
2016-04-05 18:06:17 +00:00
|
|
|
# these strings could be included in a third-party module but
|
|
|
|
# officially they were included in the 'basic' snippet for new-style
|
|
|
|
# python modules (which has been replaced with something else in
|
2016-07-21 17:58:24 +00:00
|
|
|
# ansiballz) If we remove them from jsonargs-style module replacer
|
2016-04-05 18:06:17 +00:00
|
|
|
# then we can remove them everywhere.
|
2016-04-10 19:33:16 +00:00
|
|
|
python_repred_args = to_bytes(repr(module_args_json))
|
2017-01-27 19:53:02 +00:00
|
|
|
b_module_data = b_module_data.replace(REPLACER_VERSION, to_bytes(repr(__version__)))
|
|
|
|
b_module_data = b_module_data.replace(REPLACER_COMPLEX, python_repred_args)
|
|
|
|
b_module_data = b_module_data.replace(REPLACER_SELINUX, to_bytes(','.join(C.DEFAULT_SELINUX_SPECIAL_FS)))
|
2016-04-05 18:06:17 +00:00
|
|
|
|
|
|
|
# The main event -- substitute the JSON args string into the module
|
2017-01-27 19:53:02 +00:00
|
|
|
b_module_data = b_module_data.replace(REPLACER_JSONARGS, module_args_json)
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2016-09-07 05:54:17 +00:00
|
|
|
facility = b'syslog.' + to_bytes(task_vars.get('ansible_syslog_facility', C.DEFAULT_SYSLOG_FACILITY), errors='surrogate_or_strict')
|
2017-01-27 19:53:02 +00:00
|
|
|
b_module_data = b_module_data.replace(b'syslog.LOG_USER', facility)
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2017-01-27 19:53:02 +00:00
|
|
|
return (b_module_data, module_style, shebang)
|
2015-02-10 20:35:34 +00:00
|
|
|
|
2014-11-14 22:14:08 +00:00
|
|
|
|
module_common: handle None value for templar (#36651)
* module_common: set required parameter templar
Fix the following error (related to b455901):
$ ./hacking/test-module -m ./lib/ansible/modules/system/ping.py -I ansible_python_interpreter=/usr/bin/python
Traceback (most recent call last):
File "./hacking/test-module", line 268, in <module>
main()
File "./hacking/test-module", line 249, in main
(modfile, modname, module_style) = boilerplate_module(options.module_path, options.module_args, interpreters, options.check, options.filename)
File "./hacking/test-module", line 152, in boilerplate_module
task_vars=task_vars
File "ansible/lib/ansible/executor/module_common.py", line 910, in modify_module
environment=environment)
File "ansible/lib/ansible/executor/module_common.py", line 736, in _find_module_utils
shebang, interpreter = _get_shebang(u'/usr/bin/python', task_vars, templar)
File "ansible/lib/ansible/executor/module_common.py", line 452, in _get_shebang
interpreter = templar.template(task_vars[interpreter_config].strip())
AttributeError: 'NoneType' object has no attribute 'template'
* module_common.modify_module: templar is required
2018-03-29 17:54:48 +00:00
|
|
|
def modify_module(module_name, module_path, module_args, templar, task_vars=None, module_compression='ZIP_STORED', async_timeout=0, become=False,
|
2018-01-19 21:58:10 +00:00
|
|
|
become_method=None, become_user=None, become_password=None, become_flags=None, environment=None):
|
2014-11-14 22:14:08 +00:00
|
|
|
"""
|
2015-02-10 20:35:34 +00:00
|
|
|
Used to insert chunks of code into modules before transfer rather than
|
|
|
|
doing regular python imports. This allows for more efficient transfer in
|
|
|
|
a non-bootstrapping scenario by not moving extra files over the wire and
|
|
|
|
also takes care of embedding arguments in the transferred modules.
|
2014-11-14 22:14:08 +00:00
|
|
|
|
|
|
|
This version is done in such a way that local imports can still be
|
|
|
|
used in the module code, so IDEs don't have to be aware of what is going on.
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
2015-02-10 20:35:34 +00:00
|
|
|
from ansible.module_utils.basic import *
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2015-02-10 20:35:34 +00:00
|
|
|
... will result in the insertion of basic.py into the module
|
|
|
|
from the module_utils/ directory in the source tree.
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2017-02-17 08:09:56 +00:00
|
|
|
For powershell, this code effectively no-ops, as the exec wrapper requires access to a number of
|
|
|
|
properties not available here.
|
2014-11-14 22:14:08 +00:00
|
|
|
|
|
|
|
"""
|
2017-09-12 07:11:13 +00:00
|
|
|
task_vars = {} if task_vars is None else task_vars
|
|
|
|
environment = {} if environment is None else environment
|
|
|
|
|
2016-02-27 00:41:13 +00:00
|
|
|
with open(module_path, 'rb') as f:
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2015-02-10 20:35:34 +00:00
|
|
|
# read in the module source
|
2017-01-27 19:53:02 +00:00
|
|
|
b_module_data = f.read()
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2017-12-08 14:59:24 +00:00
|
|
|
(b_module_data, module_style, shebang) = _find_module_utils(module_name, b_module_data, module_path, module_args, task_vars, templar, module_compression,
|
2017-06-27 05:58:09 +00:00
|
|
|
async_timeout=async_timeout, become=become, become_method=become_method,
|
2018-01-19 21:58:10 +00:00
|
|
|
become_user=become_user, become_password=become_password, become_flags=become_flags,
|
2017-06-27 05:58:09 +00:00
|
|
|
environment=environment)
|
2015-09-21 08:46:29 +00:00
|
|
|
|
2016-05-11 20:14:01 +00:00
|
|
|
if module_style == 'binary':
|
2017-01-27 19:53:02 +00:00
|
|
|
return (b_module_data, module_style, to_text(shebang, nonstring='passthru'))
|
2016-05-11 20:14:01 +00:00
|
|
|
elif shebang is None:
|
2018-02-22 02:03:16 +00:00
|
|
|
b_lines = b_module_data.split(b"\n", 1)
|
|
|
|
if b_lines[0].startswith(b"#!"):
|
|
|
|
b_shebang = b_lines[0].strip()
|
|
|
|
# shlex.split on python-2.6 needs bytes. On python-3.x it needs text
|
|
|
|
args = shlex.split(to_native(b_shebang[2:], errors='surrogate_or_strict'))
|
|
|
|
|
|
|
|
# _get_shebang() takes text strings
|
|
|
|
args = [to_text(a, errors='surrogate_or_strict') for a in args]
|
2016-04-05 18:06:17 +00:00
|
|
|
interpreter = args[0]
|
2018-02-22 02:03:16 +00:00
|
|
|
b_new_shebang = to_bytes(_get_shebang(interpreter, task_vars, templar, args[1:])[0],
|
|
|
|
errors='surrogate_or_strict', nonstring='passthru')
|
2016-04-05 18:06:17 +00:00
|
|
|
|
2018-02-22 02:03:16 +00:00
|
|
|
if b_new_shebang:
|
|
|
|
b_lines[0] = b_shebang = b_new_shebang
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2018-02-22 02:03:16 +00:00
|
|
|
if os.path.basename(interpreter).startswith(u'python'):
|
|
|
|
b_lines.insert(1, b_ENCODING_STRING)
|
|
|
|
|
|
|
|
shebang = to_text(b_shebang, nonstring='passthru', errors='surrogate_or_strict')
|
2016-04-05 18:06:17 +00:00
|
|
|
else:
|
|
|
|
# No shebang, assume a binary module?
|
|
|
|
pass
|
|
|
|
|
2018-02-22 02:03:16 +00:00
|
|
|
b_module_data = b"\n".join(b_lines)
|
2014-11-14 22:14:08 +00:00
|
|
|
|
2018-02-22 02:03:16 +00:00
|
|
|
return (b_module_data, module_style, shebang)
|