Wagon's Version
Always use the same version of Wagon as the one used by the targeted Cloudify Manager.
As of Cloudify 4.1.1, the version that should be used is 0.3.2
.
Wagon's Installation
Always install Wagon into a clean virtualenv
. That 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 pip
and virtualenv
). This is documented here: Preparing a Python Environment on CentOS / RHEL
To install Wagon (for example, into /tmp/wagon
):
virtualenv /tmp/wagon && /tmp/wagon/bin/pip install wagon== 0.3 . 2 |
Also, the Wagon tool must be run 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 manylinux
Bug
As per CFY-7610 - Wagons with manylinux aren't being picked up by the manager CLOSED , 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
wagon create -s <source> -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 >=
.
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.
Comments
0 comments
Please sign in to leave a comment.