After running 'openstack undercloud upgrade' successfully, then deploying the first OSP 9 overcloud, when following the official documentation to validate it with Tempest as described in: https://access.redhat.com/documentation/en/red-hat-openstack-platform/9/single/director-installation-and-usage#sect-Validating_the_Overcloud when running: $ tools/config_tempest.py --deployer-input ~/tempest-deployer-input.conf --debug --create identity.uri $OS_AUTH_URL identity.admin_password $OS_PASSWORD --network-id d474fe1f-222d-4e32-9242-cd1fefe9c14b It fails with "ImportError: No module named manila_tempest_tests.plugin" The workaround is installing python-manila-tests.noarch. If the test is part of the default set of tests in OSP 9, the package should be installed during the 'openstack undercloud upgrade' process.
Not sure if related, but https://bugzilla.redhat.com/show_bug.cgi?id=1293840 is also affecting OSP 9 even after the workaround mentioned in the description.
I had the same problem. As a workaround I removed manila without dependencies of tempest #rpm -e python-manilaclient-1.8.1-1.el7ost.noarch python-sahara-1:4.0.1-2.el7ost.noarch openstack-heat-common-1:6.0.0-11.el7ost.noarch openstack-sahara-common-1:4.0.1-2.el7ost.noarch python-heat-tests-1:6.0.0-11.el7ost.noarch --nodeps
To Manila squad to see if this is still an issue in OSP10.
(In reply to Ramon Acedo from comment #0) > After running 'openstack undercloud upgrade' successfully, then deploying > the first OSP 9 overcloud, when following the official documentation to > validate it with Tempest as described in: > https://access.redhat.com/documentation/en/red-hat-openstack-platform/9/ > single/director-installation-and-usage#sect-Validating_the_Overcloud when > running: > > $ tools/config_tempest.py --deployer-input ~/tempest-deployer-input.conf > --debug --create identity.uri $OS_AUTH_URL identity.admin_password > $OS_PASSWORD --network-id d474fe1f-222d-4e32-9242-cd1fefe9c14b > > It fails with "ImportError: No module named manila_tempest_tests.plugin" > > The workaround is installing python-manila-tests.noarch. > > If the test is part of the default set of tests in OSP 9, the package should > be installed during the 'openstack undercloud upgrade' process. Hey Ramon, Did you encounter this on an upgrade from OSP-8 -> OSP-9 or from OSP-9 -> OSP-10? Knowing this will help me determine which path I need to test. Thanks!
Hi Dustin, it was from OSP8 to OSP9
Got it, I'll try it out and see what happens!
how are we determining which tempest plugins should be installed and what package name to use for them?
(In reply to Jon Schlueter from comment #9) > how are we determining which tempest plugins should be installed and what > package name to use for them? The manila tempest tests are in the openstack/manila repository itself. So they are imported into RHOS with the main manila repo and are in lock-step with it w.r.t. commits, branch release labels, etc. Unlike the main tempest code, which is branchless. The RHOS specfile for, say rhos-10.0-rhel-7 copies them out to a separate location, they are excluded from the actual manila package, and they are used to build the python-manila-tests package. Is this what you want to know?
(In reply to Tom Barron from comment #10) > (In reply to Jon Schlueter from comment #9) > > how are we determining which tempest plugins should be installed and what > > package name to use for them? > > The manila tempest tests are in the openstack/manila repository itself. So > they are imported > into RHOS with the main manila repo and are in lock-step with it w.r.t. > commits, branch release labels, etc. Unlike the main tempest code, which is > branchless. > > The RHOS specfile for, say rhos-10.0-rhel-7 copies them out to a separate > location, they are excluded from the actual manila package, and they are > used to build the python-manila-tests package. > > Is this what you want to know? I was more looking for how do we know to install python-manila-tests? is it hard-coded into some script/puppet module/ documentation? or is it assumed to come from python-tempest-all
(In reply to Jon Schlueter from comment #11) > (In reply to Tom Barron from comment #10) > > (In reply to Jon Schlueter from comment #9) > > > how are we determining which tempest plugins should be installed and what > > > package name to use for them? > > > > The manila tempest tests are in the openstack/manila repository itself. So > > they are imported > > into RHOS with the main manila repo and are in lock-step with it w.r.t. > > commits, branch release labels, etc. Unlike the main tempest code, which is > > branchless. > > > > The RHOS specfile for, say rhos-10.0-rhel-7 copies them out to a separate > > location, they are excluded from the actual manila package, and they are > > used to build the python-manila-tests package. > > > > Is this what you want to know? > > I was more looking for how do we know to install python-manila-tests? is it > hard-coded into some script/puppet module/ documentation? or is it assumed > to come from python-tempest-all OK, that makes sense. I really don't know what assumptions are here but offhand it would make sense to do with the manila tempest plugin what is done with the other tempest plugins - e.g. sahara. I do set that you added a requirement for python-manila-tests to RHOS10 openstack-tempest in commit ba701ce10ffe36ba66f3e3ce99ce650305c68b50 and that there were already requirements there for other components. Thanks! Do you think that is sufficient to take care of the issue reported here, framed in terms of upgrade to RHOS10?
For what it's worth, I was able to upgrade a deployment from OSP-10 to OSP-11, set up and configure Tempest, and run the Manila Tempest tests successfully without running into any issues with the 2017-04-24.2 puddle. It looks like whatever issue we were seeing was solved in the intervening releases.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1245