stack.sh's use of root is primarily to support the activities that would be handled by packaging in "real" deployments. To remove additional protections that will be desired/required in production would be a step backward.
README.md. DevStack is only supported on releases other than those documented in
README.mdon a best-effort basis.
stack.sh. Support will follow the pattern set with the Ubuntu testing, i.e. only a single release of the distro will receive regular testing, others will be handled on a best-effort basis.
stack.shto handle this. But the testing on py26 is valuable so we do it...
local.conf. The primary considerations are turning off the services not required on the secondary nodes, making sure the passwords match and setting the various API URLs to the right place.
tools/info.sh) that gathers the versions of the relevant installed apt packages, pip packages and git repos. This is a good way to verify what Python modules are installed.
n-volin this example):
local.conf. Swift is on its own release schedule so pick a tag in the Swift repo that is just before the milestone release. For example:
[[local|localrc]] GLANCE_BRANCH=stable/grizzly HORIZON_BRANCH=stable/grizzly KEYSTONE_BRANCH=stable/grizzly NOVA_BRANCH=stable/grizzly GLANCE_BRANCH=stable/grizzly NEUTRON_BRANCH=stable/grizzly SWIFT_BRANCH=1.10.0
requirements.txtto grab project dependencies?
erlangnot being happy with the hostname resolving to a reachable IP address. Make sure your hostname resolves to a working IP address; setting it to 127.0.0.1 in
/etc/hostsis often good enough for a single-node installation. And in an extreme case, use
clean.shto eradicate it and try again.
[[local|localrc]] HEAT_STANDALONE=True ENABLED_SERVICES=rabbit,mysql,heat,h-api,h-api-cfn,h-api-cw,h-eng KEYSTONE_SERVICE_HOST=<keystone-host> KEYSTONE_AUTH_HOST=<keystone-host>
tools/fixup_stuff.shis broken and shouldn't 'fix' just one version of packages.
prettytablespecific problems with specific versions are being worked around. If later releases have those problems than we'll add them to the script. Knowing about the broken future releases is valuable rather than polling to see if it has been fixed.