Creating a Wagon File

Wagon’s Version

As 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 Installation

Always 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.

To install Wagon (for example, into /tmp/wagon):

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.

Work Around the manylinux Bug

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

(Replace /tmp/wagon with the path to Wagon’s virtualenv)

Wagon Tool Invocation

Download 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-dir ensures that your user’s pip cache 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:

cloudify-plugins-common==<version>

When <version> is the minimal version of Cloudify that you’d like to support.
As a rule of thumb, the value of version should match the value of the cloudify-plugins-common dependency that’s inside the plugin’s setup.py file.
For example, if your plugin’s setup.py declares this:

install_requires=[
  cloudify-plugins-common>=3.4
  ]

Then your constraints file must include:

cloudify-plugins-common===3.4

Note the difference in operators: for the constraints file, use === and not >= or ==.
If you don’t specify a constraints file as described above, the Wagon tool is very likely to always pick up cloudify-plugins-common of 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.