openstack/devstack - devstack - OpenDev: Free Software Needs Free Tools

This dumps some data in the case where we fail to wait for a child
pid to help debug what is going on. This also cleans up a few review
comments from the actual fix.
Change-Id: I7b58ce0cf2b41bdffa448973edb4c992fe5f730c
Related-Bug: #1923728 

Apparently bash (via POSIX) only guarantees a small (32ish) number of
children can be started and their statuses retrieved at any given
point. On larger jobs with lots of plugins and additional work, we
may go over that limit, especially for long-lived children, such
as the install_tempest task.
This works around that issue by creating a fifo for each child at
spawn time. When the child is complete, it will block on a read
against that fifo (and thus not exit). When the parent goes to wait
on the child, it first writes to that fifo, unblocking the child so
that it can exit near the time we go to wait.
Closes-Bug: #1923728
Change-Id: Id755bdb1e7f1664ec08742d034c174e87a3d2902

Several jobs have been running in parallel since the late Wallaby
cycle, and other developers have had it enabled locally. I have heard
no async-related stability or debug-ability complaints thus far.
I think that we should convert the default to parallel early in the
Xena cycle in an attempt to spread the speed improvements across the
board, while also collecting data on a wider set of configurations.
Change-Id: I83d56c9363d481bb6d5921f5e1f9b024f136044b

We have a *ton* of stuff in devstack that is very linear, specifically
the ten-ish minutes we spend loading osc to run a single API command
against something. We also generate configs, sync databases, and other
things that use one core of our worker and make our runtime longer
than it really needs to be.
The idea in this patch is to make it super simple to run some things
in the background and then wait for them to finish before proceeding
to something that will require them to be done. This avoids the
interleaving you would expect by redirecting the async tasks to a log
file, and then cat'ing that log file synchronously during the wait
operation. The per-task log file remains so it's easier to examine
it in isolation.
Multiple people have reported between 22-30% improvement in the
time it takes to stack with this. More can be done, but what is here
already makes a significant difference.
Change-Id: I270a910b531641b023c13f75dfedca057a1f1031