[openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

Thomas Goirand zigo at debian.org
Mon Jun 15 13:16:53 UTC 2015

On 06/15/2015 11:31 AM, Joe Gordon wrote:
> Nova itself doesn't depend on suds anymore.

A quick grep still shows references to suds (that's in Kilo, but the
master branch shows similar results):

etc/nova/logging_sample.conf:qualname = suds

nova/tests/unit/test_hacking.py:            " def

nova/tests/unit/virt/vmwareapi/test_vim_util.py:        with

nova/tests/unit/virt/vmwareapi/stubs.py:def fake_suds_context(calls=None):

nova/tests/unit/virt/vmwareapi/stubs.py:    """Generate a suds client
which automatically mocks all SOAP method calls.

mock.patch('suds.client.Client', fake_client),

nova/tests/unit/virt/vmwareapi/test_driver_api.py:import suds


nova/tests/unit/virt/vmwareapi/fake.py:    """Fake factory class for the
suds client."""

nova/tests/unit/virt/vmwareapi/fake.py:        """Initializes the suds
client object, sets the service content

nova/virt/vmwareapi/vim_util.py:import suds

nova/virt/vmwareapi/vim_util.py:    for k, v in

nova/config.py:                       'qpid=WARN', 'sqlalchemy=WARN',


> Oslo.vmware has a suds
> dependency, but that is only needed if you are using the vmware virt
> driver in nova.

It's used in unit tests, no?

> So nova's vmware driver depends on suds (it may be suds-jurko these
> days)

As I wrote, suds-jurko isn't acceptable either, as it's also not
maintained upstream.

> but not nova in general.

If we don't want suds, we don't want suds. Not just "it's only in some
parts" kind of answer. Especially, it should appear in
tests-requirements.txt and in vmwareapi unit tests. Don't you think?


Thomas Goirand (zigo)

More information about the OpenStack-dev mailing list