In RHEL under proxy, installation by stack.sh failed
because of rdo-release.rpm install failure.
This patch fixes install command for rdo-release.rpm
because it is caused by lack of http(s)_proxy.
Change-Id: I176d1e140f52e1bb0343170ba4d90c06b98d5a99
Closes-Bug: #1536478
This commit adds a success output for the entire devstack run to the
subunit output. Ideally we wouldn't need this, but because we don't
have timing data for every single operation performed by devstack we
need to do this to track the total duration of the devstack run.
To capture failures this commit adds saving a devstack event when we
trip the exit_trap. This will save a similar result to the stream in
the successful case, but instead mark it as a failure.
Depends-On: Icc7df33e4d73ba6322af38fbdf3aea230f2fcf4d
Change-Id: I07112dde996c3e2c73f5aafc9b73d33d26374633
The existing GetOSVersion has a lot of unused code which is wrong in
several ways
- the only path tested in upstream CI is with lsb_release, because
it's pre-installed on all nodes
- the /etc/redhat-release checking probably still works, but is
unnecessary
- If using lsb_release, os_UPDATE has never actually been set.
- the /etc/SuSE-release branch checking is broken if the lsb package
is actually installed. lsb checking does not set os_UPDATE but yet
the SuSE DISTRO setting relies on this to set a patch level (and so
does some of the rpm tags). SuSE 11 is up to update 3, but the rpm
matching is stuck hard-coded to update 2. I'm guessing
installation is actually broken there.
- the debian checking branch is broken. The VERSION tags have been
removed and were not supposed to be relied on anyway (see notes in
[1])
This simplifies things:
- remove OSX checking (moved here after discussions in
I31d0fdd30928ecc8d959a95838b1d3affd28ac6f)
- only use the output of lsb_release.
- A small best-effort check to pre-install lsb packages if not
detected (that avoids chicken-egg-problem of package-install
wrappers relying on os_* flags).
- The unset os_UPDATE is removed. It's only previous use was for
setting separate suse versions in the DISTRO element for matching
during package installs (since removed)
- DISTRO setting is modified to use the parts of os_RELEASE it wants.
Per-above, this is the correct place to parse out specifics.
- Call out the is_* functions, which are a better way to detect
platforms
- Export the variables as read-only, since they shouldn't be reset
[1] http://sources.debian.net/src/base-files/7.5/debian/changelog/
Change-Id: I46a2c36d95327087085df07cb797eb91249a893c
Be gone ADMIN_TOKEN, long live keystone-manage bootstrap.
This patch reworks the initial setup for keystone by using
the new bootstrap command. After a minimal service catalog
has been created, using this process, we simply authenticate
as usual.
implements bp: bootstrap
Depends-On: I113c6934b6b83ceff23a94101967a6df1126873f
Change-Id: Ia1475d461eab60b68c6a0356714b21c7f92e0194
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
Fedora 21 reached its End Of Life (EOL) on 1-DEC-2015[1]; remove it as
supported distribution.
- stack.sh: Remove Fedora 21 from list of supported distributions.
- tools/fixup_stuff.sh: Make the minimum Fedora version to be F22 in
from a conditional check in 'Python packages' section
- files/rpms/general: Remove 'f21' from NOPRIME.
- lib/ceph: Remove 'f21' from the check_os_support_ceph() function.
- doc/source/index.rst: s/Fedora 21/Fedora 22/
- pkg/elasticsearch.sh: Remove the 'if' conditional in the
install_elasticsearch() function.
[1] https://fedoramagazine.org/fedora-21-end-life-december-1st/
Change-Id: Ifbcc3dd783ff2f362a464fbf4ca22f20cc2c658e
XenServer install with devstack doesn't support local.conf, this fix
is to add support for using local.conf and backward-compatibility of
localrc
Change-Id: Ie494e01f8f1ecb8720e14392ef3f12d5a5a01dcd
Closes-Bug: #1528520
Previously horizon configuration and start are done too early
and as a result horizon init and start need to be run twice
after horizon plugins are enabled.
- horizon config was done before "run_phase stack install"
- horizon init and start were done before "run_phase stack post-config"
This commit rearrange horizon setup to the appropriate phases
defined in the devstack plugin interface.
- Configuration of horizon settings is moved to configure_horizon.
- horizon config is now called between run_phase stack install
and post-config.
- horizon init and start are now called between run_phase stack
post-config and extra.
Change-Id: I8bf2ceaf7734c4f7cec68bc05d7cdbae81ef311e
When outputting these error strings, turn off the tracing so the user
can actually read it. Also reword the "not root" user message so it
fits into a standard terminal window length.
Change-Id: I466c60865bc1128f4edd219f831a9c6cffa67829
Parital-Bug: #1517199
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
We haven't been testing master on precise for a long time, and changes
are coming that won't work on precise. If people want to keep running
on precise they should realize they are on their own with it. And that
we won't block any changes that use it.
Change-Id: I3697f1c2409ad08f49793dabb37011606188e6f6
This change allows to use f23 without the FORCE=yes option.
Make sure you have latest kernel, or you have kernel-modules
installed for the running kernel.
f21 support will be removed when the gate jobs are upgraded
to use newer fedora version.
Change-Id: I6e3e64088187a7f6da745e3cfb07524fd31782ab
Add an option to skip the EPEL & other repo installs for rhel7 based
platforms.
This option can serve two purposes; firstly as described in
I834f20e9ceae151788cec3649385da1274d7ba46 during platform bringup, a
publically available EPEL might not be available. This will allow you
to pre-configure a hand-built repo, etc. so you can continue testing.
The other thing is that in a CI system you might be frequently
building images and pre-installing EPEL/RDO etc. In that case this is
just extra work.
Change-Id: I9809449f4a43fa9b547c6e3ca92722c7f6e66d6a
devstack can call python before parsing the
package requirements, so the python installation
needs to be done eralier.
Closes-Bug: #1488625
Change-Id: I85cca899aeedd741cf7dc695435d61390e260f22
Commit title says it all. I don't know how you feel about these kind
of commits, I feel like it's a waste of resources but I also feel bad
when I see big/obvious typo.
Change-Id: If048bb2dbad1a0b5a13e56b5fa1e6ea7c01eb05e
This attempts to make the zookeeper installation a bit more modular
(assuming that other folks will want to add other dlms as plugins),
and addresses the service start issues with zookeeper under
ubuntu/upstart.
Zookeeper is not going to be installed by default. Services need to
ask for it with use_dlm.
Change-Id: I33525e2b83a4497a57ec95f62880e0308c88b34f
This has come up on the mailing list recently, we should just fail
early and explicitly so that people don't get way down this path and
not realize it's never going to work.
Change-Id: I8a7f001adf3a5244b8655858ebd5fc7014a4af55
Thanks to lifeless, pip now implicitly has a wheel cache so that it
builds a wheel before every install, and uses that cache. All our
clever attempts at manually doing wheelhouse things is actually
bypassing the existing cache and making things take longer.
We should remove all of this code and just let pip do this thing,
which is does very well, and get out of the way.
Change-Id: Ia140dc34638d893b92f66d1ba20efd9522c5923b
In Tokyo, there was a cross project session on distributed
key locking:
https://etherpad.openstack.org/p/mitaka-cross-project-dlm
In support of the discussion there, we'll need support for
a zookeeper service in Devstack and ability to use libraries
like Tooz for DLM functionality.
In this review, we pick up some configuration files from
monasca-api and copy the lib/template to implement the
zookeeper lifecycle. Those services that need zookeeper
need to add "zookeeper" in ENABLED_SERVICES.
Change-Id: Icef26e5cdaa930a581e27d330e47706776a7f98f
The interactive password prompt currently saves to .localrc.auto
However, this is removed when you re-run stack; that is required as it
is how we source the localrc bits of local.conf, and we want the
users' changes to be picked up.
The passwords, however, should remain constant, because everything has
already been setup with them. So write them to a separate file. Note
we source before localrc so it can still overwrite them.
Some minor flow-changes too
Change-Id: I9871c8b8c7569626faf552628de69b811ba4dac0
Closes-Bug: #1505872
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
This lets you specify that devstack should not be run by the user on
the box that you are on. Helps with running commands in the wrong
window.
Change-Id: I7aa26df1a2e02331d596bbfefb0697937787252f
Setup the log output before calling functions like
check_path_perm_sanity that want to write out to
the error log.
Change-Id: I9815965257c399a48f8cf0f344814d954137aecb
Closes-Bug: #1500834
As a follow-on to the issues raised by
I069f46f95656655ae7ba8f3dd929f47eae594b68, rather than a re-write of
create_userrc.sh logic, create a temporary userrc that can be helpful
for debugging until we have the whole system bootstrapped
Change-Id: I3325acffd259cf7f6f4a153c88037cfe8405ca50
This reverts commit f768787bdd6dddf2790f83a884618d29677ca77c.
And sets OS_AUTH_VERSION so swift CLI doesn't fall flat when
not using v2 keystone
Change-Id: If44a7e0d85e48020a3c90d8c5c027513129f0f3b
If `DATABASE_TYPE` is configured in `local.conf`, the database backend
is currently configured with `initialize_database_backends` even if no
database backend is enabled.
On a multi-nodes Devstack environment, such as devstack-vagrant, the
compute node currently fails because it does not have PyMysql. This
compute node has no database backend enabled, but has to connect to
the database on another node.
We should install the python client if DATABASE_TYPE is set, even
if no database backend is enabled.
Closes-Bug: 1501001
Change-Id: Iffd5f7243a0dfdbe56cf6b9a87b96ed7678c81dd
