As part of fixing the integration test agent_tests/test_existing_vm::ExistingVMTest::test_source_plugin_requires_old_package we've found out that using a 4.X package of cloudify-common with a 5.1 manager causes failures, mainly having to do with pika/rabbitmq:
We'd like for older packages of coludify-common to work with a 5.1 manager
An example that Lukasz gives is that the user packages a plugin which uses e.g cloudify-common==4.6 in setup.py. That probably shouldn’t work because 4.6 can’t run on Python 3, but the above error doesn’t seem connected to Py2 vs. Py3 so worth investigating. So,
Doesn’t seem critical, not a blocker
No (test checks only with cloudify-common==5.0.0 currently, after the latest PR)
I guess all our plugins that were ported to py3 are using common 5?
Is there a reason why a customer when porting a plugin to py3 won’t bump common version to 5?
we set cloudify-common>=4.5.5 in setup.py .
I we had similar issue when investigating mgmtworker packages.
If user runs cloudify <5.1 so the common in the plugin will be the same common as mgmtworker(mgmtworker will not allow to the plugin to install its cloudify-common).
If we are on 5.1 so every plugin has its own virtual environment and its own common.
correct me if im wrong.
My understanding from is that:
We package the plugin with 4.5.5 or whatever is the oldest supported version since the plugin was developed.
But the manager will disregard that and use the version in the management worker.
we find that 4.x common will simply Not Work™ because it's just not python3-compatible, and so currently it's not really possible to even create a wagon for it, which is able to be installed on a py3 worker