Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
CI was stuck on collecting logs. The collect-logs playbook, which
normally takes just a few minutes, took more than an hour and was
eventually killed.
The playbook was stuck on collecting LVM info on the overcloud node,
which runs this command:
(vgs; pvs; lvs) &> /var/log/extra/lvm.txt
Therefore it's very likely that the problematic part is the LVM setup
in the containerized cinder-volume service, and falling back to
non-contianerized for the time being should get the CI going
again.
Change-Id: Ib10e4f18d967d356a15b97f58c488f8402a73356
Closes-Bug: #1698136
|
|
This will set the max_active_keys setting in keystone.conf, and
furtherly we'll read this value from tripleo-common to do purging of
keys if necessary.
bp keystone-fernet-rotation
Change-Id: I9c6b0708c2c03ad9918222599f8b6aad397d8089
|
|
The list that was passed contained repeated services, which was
problematic if we wanted to use this list in puppet. So instead we pass
a list with the unique names.
Change-Id: Ib5eb0c5b59a9a50344d22c258ca461e8f1e52c86
|
|
|
|
|
|
|
|
|
|
The bootstrap_nodeid can have capital letters while the hostname may
not. In puppet we use downcase for this comparison, so let's follow a
similar pattern for scripts from THT.
Change-Id: I8a0bec4a6f3ed0b4f2289cbe7023344fb284edf7
Closes-Bug: #16998201
|
|
Add VipMap output to the top level stack output. VipMap is a mapping
from each network to the VIP address on that network. Also includes the
Redis VIP.
This output facilitates deploying split-stack so you can feed the VIP
addresses from VipMap as inputs into the services stack.
implements blueprint split-stack-default
Change-Id: I245920994613c9bd10801c25fa545267aa49b239
|
|
Add 2 new environments to faciltate deploying split-stack:
environments/overcloud-baremetal.j2.yaml
environments/overcloud-services.j2.yaml
The environments are used to deploy 2 separate Heat stacks, one for just
the baremetal+network configuration and one for the service
configuration.
In order to keep Heat's view of the server's hostname consistent across
the 2 stacks the 2 environments set the same HostnameFormat with
"overcloud" as the stack name.
implements blueprint split-stack-default
Change-Id: I0b3f282c08af6fecea8f136908b806db70bada46
|
|
The DeploymentSwiftDataMap parameter is used to set the
deployment_swift_data property on the Server resoures. The parameter is
a map of role names and node indexes to Swift container and object names
to be used for storing deployment data.
The parameter allows for using predefined Swift objects for storing
deployment data instead of container/object names with generated uuid's
from Heat.
implements blueprint split-stack-default
Depends-On: Ia07e9374a4b95bd0e74fc47fb9df4bf6ad096715
Change-Id: I471037de35e7f349d900462ec3ffb16fe2d6ebd9
|
|
Adds a new output, ServerOsCollectConfigData, which is the
os-collect-config configuration associated with each server resource.
This can be used to [pre]configure the os-collect-config agents on
deployed-server's.
Having the data available as a stack output is more user friendly than
having to query several nested levels of stack resources, and then
inspect resource metadata.
implements blueprint split-stack-default
Change-Id: Iaf062f1a72e2a9e4d97f84c67f72408a6b5cebfc
Depends-On: I8acfd67cd8138d587cc362184c84a08134bf3157
|
|
First, this parameter must match what is configured on the
undercloud, so strengthen that language.
There is also now an undercloud.conf parameter that can be used to
set the requisite options on the undercloud services, so just point
users at that rather than trying to explain how to configure the
services manually (which is error-prone and doesn't survive
undercloud updates).
Change-Id: I002cce176e3430473a29e79efde3464bddb24cc7
|
|
Depends-On: I5dc10ef5cccf6d378c20c68fc4a32d2d3c38233f
Change-Id: Ib96040c2e27ad76b1fa6ecb9468bb9d97b3c4518
|
|
|
|
|
|
The bug that prevented it from being a comma delimited list was fixed.
Change-Id: Ia5296140763849bdeac481c812f70a42d907c214
|
|
Use common volumes, and use the host log dir in DB sync container.
Co-Authored-By: Jiri Stransky <jistr@jistr.com>
Change-Id: I52602eb4ffd8834c36eec66ef845e5563f72f786
|
|
Change-Id: I8dca09372a58b6dacbb8e65602e1b0bdb6c01ae7
Related-Blueprint: example-custom-role-environments
|
|
Change-Id: Ibac65f5147413e8c5c37c513d033acf6b6e83e7b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The current port conflicts with trove. This is updated in puppet
module. See related change: https://review.openstack.org/#/c/471551/
Change-Id: Iefacb98320eef0bca782055e3da5d243993828d7
|
|
|
|
|
|
|
|
In many occasions we had log directory initialization containers
without `detach: false`, which didn't guarantee that they'll finish
before the container depending on them will start using the log
directory.
This is now fixed by moving the initialization container one global
step earlier, so that we can keep the concurrency when creating the
log dirs. (Using `detach: false` makes paunch handle just one
container at a time, and as such it can have negative performance
impact.)
For services which have their container(s) starting in step_1,
initialization cannot be moved to an earlier step, so the solution
here was to just add `detach: false`.
As a minor related change, cinder DB sync container now mounts the log
directory from host to put cinder-manage.log into the expected
location.
Change-Id: I1340de4f68dd32c2412d9385cf3a8ca202b48556
|
|
|
|
The file doesn't exist. The pxe setup is part of
puppet/services/ironic-conductor.yaml
Change-Id: I3a6f038ed69ea44f0594064b6f9657ff1b72e1bb
Closes-Bug: #1697927
|
|
|
|
|
|
|
|
|
|
When we merged If3989f24f077738845d2edbee405bd9198e7b7db we correctly
used name_lower for most things but we left out the the
OS::TripleO::Network resource which would cause errors like the
following:
Could not fetch contents for file:///tmp/tripleoclient-LdqQGJ/tripleo-heat-templates/network/internalapi.yaml
The reason is that the network filename is called internal_api.yaml.
Change-Id: I40f268668ed948e5d41ed0ff5a8fc954cef7b17c
Closes-Bug: #1697883
|
|
With the addition of the KeystoneFernetKeys parameter, it's now possible
to do fernet key rotations using mistral, by modifying the
KeystoneFernetKeys variable in mistral; subsequently a rotation could
happen when doing a stack update.
So this re-enables the managing of the key files by puppet. However,
this is left configurable, as folks might want to manage those files
out-of-band.
bp keystone-fernet-rotation
Change-Id: Ic82fb8b8a76481a6e588047acf33a036cf444d7d
|
|
This uses the newly introduced dict with the keys and paths instead of
the individual keys. Having the advantage that rotation will be
possible on stack update, as we no longer have a limit on how many keys
we can pass (as we did with the individual parameters).
bp keystone-fernet-rotation
Change-Id: I7d224595b731d9f3390fce5a9d002282b2b4b8f2
Depends-On: I63ae158fa8cb33ac857dcf9434e9fbef07ecb68d
|
|
|
|
Also attempts to move the workaround for bug #1696283 to before the
puppet apply call.
Closes-Bug: #1696622
Change-Id: I3a195466a5039e7641e843c11e5436440bfc5a01
|
|
|
|
|
|
|
|
|