Thanks for your help and sketch of solution, Andrea! -Eric From: Andrea Frittoli <andrea.frittoli at gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org> Date: Friday, July 28, 2017 at 9:03 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org> Subject: Re: [openstack-dev] [tempest][infra][congress] subprocess launched in tempest test lacks file permission > > > On Fri, Jul 28, 2017 at 4:38 AM Eric K <ekcs.openstack at gmail.com> wrote: >> A tempest test [1] launches additional instances of Congress using >> subprocess.popen and tests the coordination between them and the original >> instance launched by devstack. The problem is, the new instances are >> launched from the tempest test user rather than the user of the original >> congress instance devstack created. As a result, the new instances fail >> for being unable to access the encryption keys created by the original >> congress instance (600 permission).[2] >> >> Any suggestions for how to workaround this problem? Is it possible to >> somehow configure the gate job to run tempest tests as SU or as the >> stackuser that launches the original congress instance? Thanks so much! > > Unfortunately we don't have any facility in Tempest to control the user for > subprocesses since Tempest is meant for API testing only. Starting a > subprocess within the test sounds a bit outside of the scope of what you > may want to do in a Tempest test. > > If you want to use Tempest to verify HA type of scenarios you may want > to move the orchestration bit outside of Tempest - you could have an ansible > script that manages your services and run Tempest before and after certain > actions to verify that things are still working. > > If you want tests to run in parallel to things happening to your system you > can do that but again you will need an external component to orchestrate > this, and you don't know what kind of tempest test will be running unless > you use a single long running scenario test designed for this purpose. > > Andrea Frittoli (andreaf) > >> >> [1] >> https://github.com/openstack/congress/blob/master/congress_tempest_tests/te >> sts/scenario/congress_ha/test_ha.py.disabled#L117 >> <https://github.com/openstack/congress/blob/master/congress_tempest_tests/tes >> ts/scenario/congress_ha/test_ha.py.disabled#L117> (currently disabled, >> trying to re-enable) >> >> [2] >> http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub >> untu-xenial/607623d/logs/testr_results.html.gz >> <http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ubu >> ntu-xenial/607623d/logs/testr_results.html.gz> (find: OSError: [Errno 13] >> Permission denied: '/etc/congress/keys/aes_key¹) >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) Unsubscribe: > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170728/df992fb2/attachment.html>