cinder_driver_cert.sh restarts volume services
and needs the SERVICE_TIMEOUT variable set, but
that was being declared in stack.sh.
Rather than create another duplicate variable in
the cert script, just move the SERVICE_TIMEOUT
variable to stackrc so it can be shared like other
common variables.
Change-Id: I650697df015fed8f400101a13b6165ac39626877
Closes-Bug: 1350221
Configure nova, cinder, glance, swift and neutron to use SSL
on the endpoints using either SSL natively or via a TLS proxy
using stud.
To enable SSL via proxy, in local.conf add
ENABLED_SERVICES+=,tls-proxy
This will create a new test root CA, a subordinate CA and an SSL
server cert. It uses the value of hostname -f for the certificate
subject. The CA certicates are also added to the system CA bundle.
To enable SSL natively, in local.conf add:
USE_SSL=True
Native SSL by default will also use the devstack-generate root and
subordinate CA.
You can override this on a per-service basis by setting
<SERVICE>_SSL_CERT=/path/to/cert
<SERVICE>_SSL_KEY=/path/to/key
<SERVICE>_SSL_PATH=/path/to/ca
You should also set SERVICE_HOST to the FQDN of the host. This
value defaults to the host IP address.
Change-Id: I36fe56c063ca921131ad98439bd452cb135916ac
Closes-Bug: 1328226
For functional testing of heat-standalone it is desirable for
heat to orchestrate on the rest of the cloud which is brought up
by devstack. This change makes the following changes to enable
this when HEAT_STANDALONE=True:
- Don't register the orchestration endpoint or create any dedicated
heat accounts
- Install and configure the heat keystone V2 auth plugin instead of
the default v3
- set heat.conf [clients_heat] url so that heat can call its own
API when no orchestration endpoint is registered
- Modify create_userrc.sh to set the required heat client env
variables to work with the standalone heat
Change-Id: Idae33bf1a9d550e2575e6390d2d7c8d3b94c401d
Part 3 of a series
Re-order the setup and check bits in the top portion of stack.sh to
have a logical flow with similar things done together.
No behaviour changes are intended aside from the order of execution.
Any such changes are bugs.
* Move logging and error configuration earlier to cover initial project setup.
Change-Id: Ib16bbe20f224b1cf5e86c7a2fda0d9472c108873
The missing reference to $TOP_DIR cause stack.sh to fail when called
from outside devstack's directory
Change-Id: I7faec7720896e7dcfe60fa87fb417f22c8801eef
run_process will use screen if USE_SCREEN=True (the default),
otherwise it will simply start the requested service. Therefore
wherever screen_it used, run_process can be instead.
Where stop_screen was found it has been replaced with stop_process.
A tail_log function has been added which will tail a logfile in a
screen if USE_SCREEN is True.
lib/template has been updated to reflect the use of the new
functions.
When using sg the quoting in run_process gets very complicated.
To get around this run_process and the functions it calls accepts
an optional third argument. If set it is a group to be used with sg.
Change-Id: Ia3843818014f7c6c7526ef3aa9676bbddb8a85ca
CINDER_MULTI_LVM_BACKEND is marked as deprecated and we recommend
to use CINDER_ENABLED_BACKENDS instead now. However current warning
message shows that CINDER_ENABLED_BACKENDS will be removed.
This patch fixes the message.
Change-Id: I3ca25e4273c3abebce1cfefe1ae4af622b71e993
This commit moves check to see if screen is already running after reading
stackrc, and changes messages in check if root is running DevStack.
STACK_USER is defined in stackrc, and SCREEN_NAME can be replaced with
"a non-root account".
Change-Id: I022ed1099169a3549b7e31883abe33d6298f6fa5
Closes-Bug: #1362091
EPEL7 has updated. AFAIK there is no better way to determine this; we
could possibly scrape [1] but this just seems to replace one problem
with another (maintaining the scraping)
[1] http://download.fedoraproject.org/pub/epel/7/x86_64/repoview/epel-release.html
Change-Id: Iadf66c92fcf31edeb0f364a5b1de5d87630e9a42
Using bc 64 times in loop is too verbose and slow,
replacing the echo/bc loop with hexdump and urandom.
The hexdump approach is 75 times faster and
does not floods the debug logs.
Using the common function for generating,
this kind of string with lib/heat and by the read_password.
Change-Id: If6a86dfaf0c21e2635c6de0a7b96a8ed7ec5b507
In order to use dstat on the new side of grenade, pull dstat code into
its own lib with the function start_dstat
Change-Id: I5c908d594a6f3a90ed4b3f744002bf606841cf07
This is only triggered if HEAT_CREATE_TEST_IMAGE is True
This custom image contains the following:
* heat-cfntools from git rather than the packaged version, which
will allow gating on heat-cfntools changes
* os-collect-config, os-apply-config, os-refresh-config, which
will allow gating on these projects, and will allow heat
software-config tests to be written
* software-config hooks from heat-templates, which will allow tempest
tests to be written for software-config with different configuration
tools (script, puppet, cfn-init etc)
The heat functional tests will soon replace the heat-slow tempest job,
so heat-slow tempest configuration will be removed after the heat
functional test job is gating.
Change-Id: I2e0490c1662a184d4c6d8c7e9ebb128e1912f1b0
These projects contain agents which can be installed on custom
images. Installing these repos will allow a future change to
build a custom image containing these projects. This will allow
gating on any changes in these projects by running heat-slow
on the custom image.
The corresponding devstack-gate change is
https://review.openstack.org/#/c/92055/
Change-Id: I7b1343c094f755f79ddeb1bac3ff4c0daa3fb70c
If LOGDIR is undefined, we'll end up calling worldump with the `-d` option but
pass in an empty string as the option value. This causes an argument parsing
error inside worlddump.
The proposed fix is to detect if LOGDIR is undefined, and if so, omit the `-d`
argument.
Change-Id: I77968849ebd3e3bebd2e5929b87b60fc1b6541bf
Closes-Bug: 1333321
Part 2 of a series
Re-order the setup and check bits in the top portion of stack.sh to
have a logical flow with similar things done together.
No behaviour changes are intended aside from the order of execution.
Any such changes are bugs.
* Consolidate DEST dir setup
* Move rpc & database init to just before project init
Change-Id: I2af1d4ed32ec34417c04592bf94fe645bb97f831
Part 1 of a series
Re-order the setup and check bits in the top portion of stack.sh to
have a logical flow with similar things done together.
No behaviour changes are intended aside from the order of execution.
Any such changes are bugs.
* Do sanity checks that have no configuration needs earlier
* Do supported distro check earlier
Change-Id: I7d15bac199d6c4382d4a4d222784d34f2707da56
On my devstack environments I'm now always getting the Q_AGENT
warnings even though I don't have neutron enabled. This is mostly
confusing.
For these juno warnings lets just make sure that the whole thing
only prints out in the case where we've actually got that service
enabled.
Change-Id: I7d1bb2e65594c8bee2f572ca58a1b666e5d6caed
The upstream rackspace image has a bunch of pip installed packages as
cloud-init was installed via pip due to a lack of available system
packages. This can break further system package installs, such as
markdown, which fails with
---
Error unpacking rpm package python-markdown-2.4.1-1.el7.noarch
error: unpacking of archive failed on file
/usr/lib/python2.7/site-packages/Markdown-2.4.1-py2.7.egg-info: cpio: rename
---
Because that is a directory for the pip-installed package, and a file
in the RPM
Remove all pip installed packages on rackspace images before we start
to work around this. I have filed an upstream issue with Rackspace
(ticket-id 140804-ord-0000134) and the issue is being worked on.
Change-Id: Id12d175143ed3b8e024d057d65fa67505c08042a
With rhel6 & rhel7 having a common prefix, use an exact match to make
sure we don't mix them up. This is breaking Centos7.
Change-Id: Ia4665ea78f0bafeaa2b2284a6d3de4474ea195e9
According to the comments in stack.sh the configuration parameter
Q_DHCP_EXTRA_DEFAULT_OPTS should be removed during the Juno cycle.
Change-Id: I3b38ff57f00e93e6d9692f516291f7129584bc74
According to the comments in stack.sh the configuration parameter
EXTRA_OPTS should be removed during the Juno cycle.
Change-Id: Ic71d38d6f9b8a8949e45ce3321d593ee2f8feb40
