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
This adds some safety checks to the stack user creation script.
This includes:
- Using set -o errexit to exit early on errors
- Make sure STACK_USER is set before doing anything with it
Change-Id: If027daddd03e32c5ba3c2ebb05ad5b27d2868b0a
A few Markdown-oriented issues were causing Docutils errors to
leak into the end-user docs on http://devstack.org
Change-Id: I51fa9698afb1bfb48596478d83bd1fdcd84ac52e
Automatically creating a new user account is not always the right course
of action when stack.sh is running as root. Plus, the re-exec did not
work correctly in some cases.
* Create tools/create-stack-user.sh to set up a suitable user
for running DevStack
* Abort stack.sh and unstack.sh if running as root and suggest creating a
suitable user account.
Change-Id: I5d967c00c89f32e861449234ea8fe19261cd9ae3