dhcp unit tests prompt for sudo password

Filing a fix shortly.

Fix proposed to branch: master
Review: https://review.openstack.org/28836

Reviewed: https://review.openstack.org/28836
Committed: http://github.com/openstack/quantum/commit/91b56e41eecf2cd8b4c848b4e773a1be307b40c3
Submitter: Jenkins
Branch: master

commit 91b56e41eecf2cd8b4c848b4e773a1be307b40c3
Author: armando-migliaccio <email address hidden>
Date: Fri May 10 13:10:02 2013 -0700

    Do not require sudo/rootwrap to check for dnsmasq version

    The dnsmasq version check does not need root privileges
    to run as with low privs it works just fine. As a side
    effect, the use of the rootwrapper was causing unit tests
    to hung because the execute call in check_version was not
    being stubbed out. Weirdly enough this wasn't caught in
    a previous Gerrit run; there must be a passwordless sudo
    lurking around somewhere in the Gerrit infrastructure.

    Fixes bug #1178800

    Change-Id: I4d0bd218768eec2439d3907587682ff35884a262

Adding an openstack-ci task to check why this was not caught at the gate... Are we running tests as some privileged user ?

Hi,

We have two protections against this sort of thing in Jenkins:

1) The jenkins user on the unit test slaves does not have general sudo ability, so all sudo commands will fail (there may be a password prompt).

2) We have a script that detects whether a sudo attempt occurred, and fails the test with an appropriate error message.

In examining the logs from these tests, we found that the sudo command was run, but failed. That suggests that while this test causes sudo to be run, the test itself does not fail if sudo fails (at least, not in the way that sudo fails when invoked under Jenkins). So layer (1) above holds.

Unfortunately, when we moved the test runners to quantal, the sudo log format changed, and our sudo detection script in (2) did not catch it, and so did not explicitly fail the test for having attempted to run sudo. This will be rectified shortly as we move the test runners back to precise (and the next time we change test runners, we'll check if the script needs updating).

Adding to the explanation in #5, we also did not catch it on the new CentOS slaves for similar reasons (sudo patterns in the logs being different than on Ubuntu Oneiric/Precise). This has since been patched ( https://review.openstack.org/28649 ).

The switch from quantal to precise slaves took place yesterday without incident, so this regression is no longer present.

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/29629