Wagon's VersionAs of Cloudify 4.2, the version that should be used is
0.3.2. Always use the same version of Wagon as the one used by the targeted Cloudify Manager. Note, this is not the same version of wagon that is packaged in the CLI, when you download it from PyPI.
Wagon's InstallationAlways install Wagon into a clean
virtualenv. This will reduce the chance of conflicts between packages that are already in your
virtualenv, and the versions picked up to be in the resulting Wagon file.
Make sure that your environment has the proper Python modules (such as
virtualenv). This is documented here: Preparing a Python Environment on CentOS / RHEL
virtualenv /tmp/wagon && /tmp/wagon/bin/pip install wagon==0.3.2
Wagons must be packaged on the same operating system & version as the one where the plugin is supposed to be installed.
- If the plugin has workflows, or has operations that run on the manager's side, then the Wagon tool must be run on CentOS 7.x and/or RHEL 7.x (depending on which platform the customer uses).
- If the plugin has operations that run on the agent's side, then the Wagon tool must be run on an identical platform as the one the agent is going to be run on.
- The version of Python that is used to run the Wagon tool, must be identical to the version of Python that the resulting Wagon is going to be installed on. This is especially important for plugins containing agent-side operations, which you'd like to be supported on CentOS 6.x or RHEL 6.x.
If you know for sure that your plugin, and all of its transitive dependencies, are pure Python (that is, they don't require any platform-specific artifacts), then you can run the Wagon tool on any platform, as long as there's a match between the Python minor version (2.6 vs. 2.7) you use to run Wagon, and the Python version of the target platform.
Work Around the
As per CFY-7610, as long as Wagon 0.3.2 is being used on the manager, you should disable PEP 513 support in the Wagon tool's virtualenv. This can be done by executing the following command:
echo "manylinux1_compatible = False" > /tmp/wagon/lib/python2.7/site-packages/_manylinux.py
/tmp/wagonwith the path to Wagon's virtualenv)
Wagon Tool InvocationDownload the plugin's source code to a file located at <source> and execute the wagon creation command:
wagon create -s <source> --validate -v -f -a '--no-cache-dir -c <constraints-file>'
--no-cache-dirensures that your user's
pipcache directory is not used. While that may slow the process down a bit, it results in a safer invocation. The cache directory may include Python packages that are no longer publicly available, or — more frustratingly — containing Cloudify packages that were taken from pre-release tags (our current build systems often creates tags before the official release; those tags may be moved closer to the release date). The constraints file is very important. It should contain one entry:
<version>is the minimal version of Cloudify that you'd like to support. As a rule of thumb, the value of
versionshould match the value of the
cloudify-plugins-commondependency that's inside the plugin's
setup.pyfile. For example, if your plugin's
install_requires=[ cloudify-plugins-common>=3.4 ]
==. If you don't specify a constraints file as described above, the Wagon tool is very likely to always pick up
cloudify-plugins-commonof the latest available Cloudify version, which is not what you want. Curious users might enjoy referencing this script that we use in our plugins build system.
Article is closed for comments.