Fix an issue where apt-get consistently hangs due to a SIGTTIN being
received. This occurs on a 'vanilla' devstack-gate VM, when running an
ironic-grenade job.
Upstream has a bug related to this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555632http://www.gnu.org/software/libc/manual/html_node/Job-Control-Signals.html
Macro: int SIGTTIN
A process cannot read from the user's terminal while it is running
as a background job. When any process in a background job tries to
read from the terminal, all of the processes in the job are sent a
SIGTTIN signal. The default action for this signal is to stop the
process. For more information about how this interacts with the
terminal driver, see Access to the Terminal.
Change-Id: I8b1f3dccf329bb88e017eff7492da5e701b4892c
Closes-Bug: #1532080
Not all yum failures has to be considered
catastrofic failures also because install_package
function should implement the same behavior in Fedora,
CentOS and Ubuntu. Let return the error to be solved at higher
level.
Change-Id: Ia33bb98f47017f6ec00eb3b7261ed42d72efc573
Closes-Bug: #1522590
Boolean logic used in install_package was wrong:
on nominal flow packages were actually installed twice.
This should fix it.
Change-Id: Ia465414936b272d04523a11f83d6ded378fe1daf
Closes-Bug: #1518544
Add "KVM for IBM z Systems" to the list of Fedora-like distros.
As the distribution does not have a dedicated kvm package,
prevent the installation of the kvm package during the libvirt
setup.
Change-Id: Ibb5c60797d6867264f9dea7fea85cdf1d7c72ded
Change I855ffe9c7a75e9943106af0f70cf715c34ae25c5 and
I368fec44858bd97fc6a314fb20eed2b10932cbb1 added timing
infrastructure which hides the return value of
the main commands. Restore the prior behaviour.
Change-Id: I4a536abefa7824ac6d42e7bbbf1079d9cc055984
Closes-Bug: #1518545
Those were originally used to bootstrap with admin-token from keystone,
but the openstack client is fully configured now, leaving no reason to
not just use the actual users that are there.
Change-Id: I80bdee33a78a97f5d3910aa36dc331f19780d2f1
Currently, the function create_heat_accounts uses the OS_URL and
OS_TOKEN environment variables. This is a bad choice for several
reasons, most importantly we are sending the "ADMIN_TOKEN" value
as a header. There is also no reason to not use a standard admin
user to create these resources.
Change-Id: I70b41d69917b9e53ad09c2c61e022ef09a50acfd
This removes all of the ironic code from the devstack tree, in favor of
the devstack plugin in Ironic's tree.
Depends-On: I659e3de5c64df798441798ff48ba5c9c0506585a
Depends-On: I2c52bc014f1b0dbc6b0ae22a4deb4132b4c28621
Change-Id: I5125fce295c79600781469c2f48bea80e7600081
Using absolute names for the symlink breaks in quite a few ways;
* when creating a tar file of the logs,
* when serving via NFS,
or any other case where the directory gets transferred to
a different machine.
So just create the symlink with relative names, then they'll work
in any location.
Change-Id: I432a69754985fc71feb0068b7adca01066d7bc1b
This removes the generic extras.d support, which we said we'd do at
Mitaka-1. In tree extras.d continues to function as before, though we
need stories to get ceph and ironic into plugins, and a better
solution for Tempest.
Change-Id: I8b134446dc08a2c3852423ca71af2f469f85496e
Ubuntu's apt mirroring mechanism produces inconsistent mirrors pretty
regularly. The devstack-gate apt-get update model seems to have been
more effective getting past this than what we did in devstack. Adopt
that method for our updates.
Change-Id: I97c7896ef38b275aacb4f933fc849acee1bab858
I noticed this when debugging some grenade issues failures.
An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.
We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.
When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).
The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.
The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.
Some files had already discovered this. In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste. This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.
Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
In some niche setups it is desirable to run OpenStack services under
screen, but undesirable to automatically keep a persistent log from
each service.
Add a new variable SCREEN_IS_LOGGING that controls if screen logs each
window to disk automatically.
Ideally screen itself would be configured to log but just not activate.
This isn't possible with the screerc syntax. Temporary logging can still
be used by a developer with:
C-a : logfile foo
C-a : log on
Change-Id: I2a3abf15dea95ae99ddbdfe1309382df601b7d93
Add a quick check so we don't reintroduce bad arguments as in
Ie1b8d09369281059d21da61b2725a457f708ae9e
Change-Id: Ibebc71791f2743eef64d6f7c2596d54a73ea92aa
When keystone API v3 was introduced, filtering regions when listing
endpoints was not supported (see [1]). This caused multi-region devstack
deployments to fail (see [2]). A workaround was introduced to devstack
to enable for multi-region deployments until region filtering would work
in keystone API v3.
Now that the bug related to region filtering in keystone is resolved,
the workaround should be removed.
[1]: https://bugs.launchpad.net/keystone/+bug/1482772
[2]: https://bugs.launchpad.net/devstack/+bug/1483784
Closes-Bug: #1511745
Related-Bug: #1483784
Related-Bug: #1482772
Change-Id: I52d13c3f5e7b77a7f8fb1be4dcea437988ebddfe
Bashate 0.3.2 has a few new checks -- firstly make sure some of the
plugins have #!/bin/bash, and fix up a couple of "local" changes that
were missed by I9c8912a8fd596535589b207d7fc553b9d951d3fe
Change-Id: I9e4b1c0dc9e0f709d8e76f9c9bf1c9478b2605ed
After having migrated the copies of clouds.yaml to just consume from
/etc, remove the duplicate copy.
Change-Id: I036704734785958c95d2234917d7b40bd797a375
This fails in the environment where sudo does not have permissions to
write in /home/$USER folder, e.g. [1]
Also clean-up the comment/variable usage a bit; the location isn't
actually variable at all (and that's fine, but we don't need a global
here)
[1] http://144.76.193.39/ci-artifacts/228979/10/Nova-ML2-Sriov/console.html.gz
Change-Id: I6807eae9d1c27219aa7c19de29f24fa851aa787c
There are more than one user that need to access clouds.yaml values
in tests. Rather than copying the file everywhere, simply output
it to /etc/openstack.
However, we have things copying it at the moment, so output to
both places. A follow up patch will remove the homedir version.
Change-Id: I21d3c2ad7a020a5ab02dc1ab532feae70b718892
These functions commonly externally called (as part of stackrc
inclusion, even) and do a fair bit of iteration over long
service-lists, which really fills up the logs of devstack and grenade
with unnecessary details.
The functions are well tested by unit-tests, so we are very unlikely
to need to debug internal issues with them in a hurry. Thus turn
logging down for them.
Change-Id: I63b9a05a0678c7e0c7012f6d768c29fd67f090d2
this adds a timing infrastructure to devstack to account for time
taken up by set of operations. The first instance of this is
accounting the time taken up by doing apt_get calls.
Change-Id: I855ffe9c7a75e9943106af0f70cf715c34ae25c5
With the advent of plugins and their settings files it has become
possible to disable_service in local.conf only to have the service
re-enabled in a plugin settings file. This happens because of
processing order.
To get around this the disable_service function now aggregates
service names into a DISABLED_SERVICES variable which is then checked
during enable_service. If something tries to enable something that
was previously disabled, a warning is produced in the log and the
service is not enabled.
Then after all configuration has been sourced a final check is to
done by verify_disabled_services to confirm that something has not
manually adjusted ENABLED_SERVICES to overcome a previously called
disable_service. If something has, the stack dies with an error.
Change-Id: I0f9403f44ed2fe693a46cd02486bd94043ce6b1a
Closes-Bug: #1504304
As a follow-on to I8cefb58f49dcd2cb2def8a5071d0892af520e7f7, put in
some detection around missing variable-to-test arguments in
trueorfalse.
Correct a couple of places where we were passing in blank strings,
resulting in the default always being applied.
Add test-cases and enhance the documentation a little.
Depends-On: I8cefb58f49dcd2cb2def8a5071d0892af520e7f7
Change-Id: Icc0eb3808a2b6583828d8c47f0af4181e7e2c75a
This adds a warning for extras.d usage. This will give us something to
keep an eye on in logstash to build up the list of projects that will
break at Mitaka-1.
This also makes the deprecated handling done through a function, which
will hopefully make it more consistent in the future.
Change-Id: Icd393bc3e7095fe58be0fd13ef74fece3aa5c5f1
Ia0957b47187c3dcadd46154b17022c4213781112 proposes to have bashate
find instances of setting a local value. The issue is that "local"
always returns 0, thus hiding any failure in the commands running to
set the variable.
This is an automated replacement of such instances
Depends-On: I676c805e8f0401f75cc5367eee83b3d880cdef81
Change-Id: I9c8912a8fd596535589b207d7fc553b9d951d3fe
