In a regular system, barbican is initially started by systemd during
bootstrap as barbican-api.service and later on it should be moved to
under SM lifecycle.
With [1] the service was decoupled from sm slice in cgroups, so new
expectation would be to see openstack-barbican-api.service running.
However, it was observed on a subcloud deployment that barbican was
still being managed by systemd and running.
This caused openstack-barbican-api.service to fail due to barbican
bind port already in use, and SM to be in loop starting barbican-api
service.
This change checks if barbican-api.service initialized during bootstrap
is still running. If so, stop and disable it before initialized
barbican-api through systemd-run command.
Moreover, since there is a logrotate definition for
/var/log/barbican/barbican-api.log defined in
/etc/logrotate.d/barbican-common this change also sets the
StandardOutput and StandardError systemd-run parameters from 'file'
to 'append'.
[1] https://review.opendev.org/c/starlingx/ha/+/948675
Test Plan:
PASS: build-pkgs
PASS: Install ISO and bootstrap
PASS: barbican-api.service must be inactive after sm is started
PASS: Replicate the odd behavior of barbican-api.service:
systemctl start barbican-api.service
It was noticed that sm calls the <start> method on any change
on PIDFile, so SM should stop barbican-api.service whenever it
starts, since it changes the PIDFile. Check barbican-api.log
for these messages:
INFO: Barbican start
INFO: OpenStack Key Management API (barbican-api) managed by
systemd identified. Stopping it...
Check barbican-api.service status, it should be inactive.
Partial-Bug: 2122366
Change-Id: I6c0470a93c03221b0c78e4a83097c06829ebd2ec
Signed-off-by: Alyson Deives Pereira <alyson.deivespereira@windriver.com>
f1d132c894