On 12 August 2016 at 08:13, Matt Riedemann <[email protected]> wrote:
> I opened a bug yesterday against novaclient for running the functional > tests against a neutron-backed devstack: > > https://bugs.launchpad.net/python-novaclient/+bug/1612410 > > With neutron being the default in devstack now, people hacking on > novaclient and running functional tests locally are going to have a hard > time since the tests are unconditionally written with the assumption that > the backing devstack is using nova-network. > > So we need to make the tests conditional, the question is what's the best > way? > > We could use a config like how Tempest does it, but where does that > happen? In the clouds.yaml, or the post_test_hook.sh, other? > > Another idea is the base functional test that sets up the client just > checks the keystone service catalog for a 'network' service entry, > somewhere in here: > > https://github.com/openstack/python-novaclient/blob/232711c0 > ef98baf79bcf4c8bdbae4b84003c9ab9/novaclient/tests/functional/base.py#L116 > > Thoughts on either approach or something completely different? Doesn't it make sense to configure the functional tests for novaclient to make devstack work on a nova-net backend, and introduce a new non-voting job used to flush out the new backend option, and transition over the old job to the new one in due course? > > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
