8 Commits

Author SHA1 Message Date
Jill Rouleau
971d97bf99 Correct file modes for rpmlint failures
Numerous files have incorrect modes set. Correct these so that executables
have 755 and yaml files are 644 to address rpmlint errors.

Change-Id: I8db36209b41a492f6b85e3469994de884bf556e8
2018-12-14 13:21:28 -07:00
Martin Schuppert
a99820a80c nova_compute fails to start in tls-everywhere configuration
With tls-everywhere enabled connecting to keystone endpoint fails
to retrieve the URL for the placement endpoint as the certificate
can not be verified. While verification is disabled to check the
placement endpoint later, it is not to communicate with keystone.
This disables certificate verification for communication with
keystone.

Related-Bug: 1784155

Change-Id: I317dd62f3a555f375d540a63c21a6fb38d37ca96
2018-12-03 17:07:28 +01:00
Martin Schuppert
cc61ff93ec Change step to start nova placement and make compute wait for it
There is a deployment race where nova-placement fails to start if
the nova api db migration have not finished before starting it.
We start nova placement early to make sure it is up before the
nova-compute services get started. Since in HA scenario there is
no sync in between the nodes on the current worked deployment step
we might have the situation that the placement service gets started
on C1/2 when the nova api db sync is not yet finished on C0.

We have two possibilities:
1) start placement later and verify that nova-computes recover correct
2) verify that db migration on nova_api db finished before start nova-
placement on the controllers

2) which was addressed via https://review.openstack.org/610966 showed
problems:
a) the docker/podman container failed to start with some file not found
error, therefore this was reverted in https://review.openstack.org/619607

b) when the scrip were running on different controllers at the same
time, the way how nova's db_version() is implemented has issues, which
is being worked on in https://review.openstack.org/619622

This patch addresses 1) and moves placement service start to step_4
and adds an additional task on the computes to wait until the placement
service is up.

Closes-Bug: #1784155

Change-Id: Ifb5ffc4b25f5ca266560bc0ac96c73071ebd1c9f
2018-11-26 17:44:47 +01:00
Emilien Macchi
ba30607ec6 Revert "Verify nova api migration finished before start placement"
This reverts commit c19b58a9f312bbe2ef0183f08e6773431eba6fe6.
Related-Bug: #1804434

Change-Id: I801a53e1cf2ec923b8294824f6738bedbc30bdf7
2018-11-22 16:22:09 +00:00
Zuul
0561a3536a Merge "Verify nova api migration finished before start placement" 2018-11-19 18:39:27 +00:00
Alex Schultz
a6408f0c09 Add python shim for docker config scripts
Unfortunately we may not necessarily know what version of python is
available in the containers when we run some python config scripts. In
order to work around this we have a pyshim which will try and find an
existing version of python available to run the script under. The
pyshim.sh will try python3 then python2 then python.

Depends-On: https://review.openstack.org/#/c/617716/
Change-Id: Ie08481722e9b22bb67d5282828df0941f37a140a
Closes-Bug: #1803411
2018-11-15 15:06:56 +00:00
Martin Schuppert
c19b58a9f3 Verify nova api migration finished before start placement
There is a deployment race where nova-placement fails to start if
the nova api db migration have not finished before starting it.
We start nova placement early to make sure it is up before the
nova-compute services get started. Since in HA scenario there is
no sync in between the nodes on the current worked deployment step
we might have the situation that the placement service gets started
on C1/2 when the nova api db sync is not yet finished on C0.

We have two possibilities:
1) start placement later and verify that nova-computes recover correct
2) verify that db migration on nova_api db finished before start nova-
placement on the controllers

This is a way to address 2) and should be the less invasive change as
we make sure placement gets started after the nova api db sync finished
and does not move the start to a complete different step which might
introduce any unforeseen behavior.

Change-Id: Ifc4346658cea5355bf89f6d7023ed846d9162b3e
2018-10-18 13:26:58 +02:00
Oliver Walsh
58624abf5f Improve nova statedir ownership logic
The nova_compute container kolla config is currently set to recursively change
the ownership of /var/lib/nova to nova:nova on startup.

This is necessary when upgrading from an non-container deployment to a
containerized deployment as the nova uids are not consistent across the host
and container image.

If the nova instancedir is an NFS mount then open filehandles are
broken and every VM using that NFS export fails with I/O errors.

This change re-implements the nova statedir ownership logic to target only the
files/directories controlled by nova.

Requires dist-git change: https://review.rdoproject.org/r/14734

Change-Id: I57d421feb6356d28002e77fb9bfa50a397758cbf
Closes-bug: 1778465
2018-07-09 17:07:30 +01:00