Open Stack

On 11/21/2017 04:04 PM, Jeremy Stanley wrote:
> Removing network access from the machines running these jobs won't
> work, of course, because our job scheduling and execution service
> needs to reach them over the Internet to start jobs, monitor
> progress and collect results.

Right.

> As you noted, faking Python out with
> envvars pointing it at nonexistent HTTP proxies might help at least
> where tests attempt to make HTTP(S) connections to remote systems.
> The Web is not all there is to the Internet however, so this
> wouldn't do much to prevent use of remote DNS, NTP, SMTP or other
> non-HTTP(S) protocols.

To my experience, in the vast majority of cases, setting-up the env vars
is enough to prevent problems. There was a few (non test failure
producing) DNS access, IIRC with glanceclient, but that's all I noticed.

> As such, any proxy envvar setting would
> need to happen within the scope of tox itself so that it will be
> able to set up the virtualenv prior to configuring the proxy vars
> for the ensuing tests.

This is a workable solution, though it involves patching absolutely all
projects tox.ini. I'm certain I don't have enough available time to
produce 300+ tox.ini patches and follow their review. Wouldn't there be
a more global approach?

> It might be easiest for you to work out the
> tox.ini modification on one project (it'll be self-testing at least)
> and then once the pilot can be shown working the conversation with
> the community becomes a little easier.

Doing this kind of a patch at first on a few project's tox.ini,
absolutely! I might even start with Horizon and PBR (yes, there's a
problem there as well... which I haven't reported yet). Though
generalizing it to 300+ patches, I'm really not sure. Your thoughts?

Cheers,

Thomas Goirand (zigo)