+++ This bug was initially created as a clone of Bug #1737621 +++ +++ This bug was initially created as a clone of Bug #1737366 +++ Description of problem: Keystone process is launched with multiple '-DFOREGROUND'. A sample process status: root 1 0 0 Jul26 ? 00:00:26 /usr/sbin/httpd -DFOREGROUND -DFOREGROUND keystone 18 1 0 Jul26 ? 00:04:33 keystone-admin -DFOREGROUND -DFOREGROUND keystone 19 1 0 Jul26 ? 00:04:32 keystone-admin -DFOREGROUND -DFOREGROUND keystone 20 1 0 Jul26 ? 00:04:31 keystone-admin -DFOREGROUND -DFOREGROUND keystone 21 1 0 Jul26 ? 00:04:30 keystone-admin -DFOREGROUND -DFOREGROUND keystone 22 1 0 Jul26 ? 00:04:39 keystone-admin -DFOREGROUND -DFOREGROUND keystone 23 1 0 Jul26 ? 00:04:36 keystone-admin -DFOREGROUND -DFOREGROUND keystone 24 1 0 Jul26 ? 00:04:28 keystone-admin -DFOREGROUND -DFOREGROUND keystone 25 1 0 Jul26 ? 00:04:25 keystone-admin -DFOREGROUND -DFOREGROUND keystone 26 1 0 Jul26 ? 00:04:33 keystone-admin -DFOREGROUND -DFOREGROUND keystone 27 1 0 Jul26 ? 00:04:33 keystone-admin -DFOREGROUND -DFOREGROUND keystone 28 1 0 Jul26 ? 00:04:32 keystone-admin -DFOREGROUND -DFOREGROUND keystone 29 1 0 Jul26 ? 00:04:34 keystone-admin -DFOREGROUND -DFOREGROUND Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Deploy overcloud with RHOSP13z7. 2. Check process information on a controller node. 3. Actual results: keystone process is launched with multiple '-DFOREGROUND'. Expected results: The process is launched with a single '-DFOREGROUND'. Additional info: Upstream Launchpad: https://bugs.launchpad.net/tripleo/+bug/1832090 Gerrit: https://review.opendev.org/#/c/664135/ --- Additional comment from Nathan Kinder on 2019-08-05 21:06:40 UTC --- QE verification steps: - Deploy OSP (deplolyment topology/details are not important. You just need 1 controller with Keystone.) - Run 'ps -ef | grep keystone' on the overcloud controller to confirm that "-DFOREGROUND" is specified only once per keystone process.
Hi Nathan, I need your advice. In upstream, cherry-picking the commit in stable/stein to stable/rocky is failed. The reason of the failure is from Stein is change the templates for puppet and docker into a flatten file in keystone. ~~~ commit 40ba776463b24afb7feec574999da66a5b63a028 Author: Juan Antonio Osorio Robles <jaosorior> Date: Mon Nov 5 14:43:29 2018 +0200 Flatten Keystone service configuration This change combines the previous puppet and docker files into a single file that performs the docker service installation and configuration. With this patch the baremetal version of keystone has been removed. Related-Blueprint: services-yaml-flattening Change-Id: I6140b02ad1ab6d88990e173dcf556977f065b3c5 ~~~ Is there any way to apply the patch to docker/services/keystone.yaml via git command? Or should I create a new commit for rocky and queens without cherry-pick? Kind Regards, Keigo Noha
(In reply to Keigo Noha from comment #1) > Is there any way to apply the patch to docker/services/keystone.yaml via git > command? > Or should I create a new commit for rocky and queens without cherry-pick? Hi Keigo, I have created a cherry-pick for Rocky upstream, though the actual conflict needs to be manually resolved due to the refactoring you mentioned. Once this merges for stable/rocky, we can cherry-pick this for queens as well (which will be tracked in the OSP13 BZ clone of course).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3745