integ/config/puppet-modules/openstack/puppet-keystone-17.4.0/debian/patches/0003-Update-Barbican-admin-secret-s-user-project-IDs-duri.patch
lzhu1 13568d6acc Debian: Fix openstack secret get failure
Correct the required exec resource title for updating DC keystone
admin user/project IDs section.

The exec resource title was renamed from "keystone-manage bootstrap"
to "keystone bootstrap" in Debian. Update this patch accordingly.

Test Plan:
Verified: successfully get openstack secrets after DC installation
          and Subcloud managed on Debian.

Story: 2010119
Task: 46218

Signed-off-by: lzhu1 <li.zhu@windriver.com>
Change-Id: I5dd9f06436903a01b564f44004058438a93de8b6
2022-09-09 15:56:33 +00:00

77 lines
3.4 KiB
Diff

From 127b8a6d5b8845a25044f3000a8a14d032546135 Mon Sep 17 00:00:00 2001
From: Dan Voiculeasa <dan.voiculeasa@windriver.com>
Date: Mon, 20 Sep 2021 17:25:11 +0300
Subject: [PATCH] Update Barbican admin secret's user/project IDs during
bootstrap
Adapt 0006-update-Barbican-admin-secret-s-user-project-IDs-duri.patch
from CentOS.
This will break exisiting funtionality because $dc_admin_user_id and
$dc_admin_project_id are moved to keystone::bootstrap class from
bootstrap class to keep the timing specied in the original patch.
Move is due to upsream split of init.pp.
https://github.com/openstack/puppet-keystone/commit/bc1ff1d7cb01ac02790c3302a3da6e994598d9f6
ORIGINAL MESSAGE:
In a DC system when subcloud is managed, keystone user/project IDs are
synced with Central Cloud, including admin user and project. But the
admin's secrets in Barbian still use the original user/project IDs,
causing docker registry access failure when platform-integ-apps is
reapplied.
This updated keystone admin user/project IDs to be the same as Central
Cloud right after keystone is bootstrapped during subcloud deployment.
This way any referece to admin user/project IDs after bootstrap will be
using the IDs same as Central Cloud, including the ones in Barbican.
This will solve the problem of registry access failure issue.
Closes-Bug: 1851247
Signed-off-by: Andy Ning <andy.ning@windriver.com>
END ORIGINAL MESSAGE
Signed-off-by: Dan Voiculeasa <dan.voiculeasa@windriver.com>
---
manifests/bootstrap.pp | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/manifests/bootstrap.pp b/manifests/bootstrap.pp
index d8db334..8a2feea 100644
--- a/manifests/bootstrap.pp
+++ b/manifests/bootstrap.pp
@@ -69,6 +69,8 @@ class keystone::bootstrap (
$internal_url = undef,
$region = 'RegionOne',
$interface = 'public',
+ $dc_admin_user_id = undef,
+ $dc_admin_project_id = undef,
) inherits keystone::params {
include keystone::deps
@@ -108,6 +110,22 @@ class keystone::bootstrap (
tag => 'keystone-bootstrap',
}
+ if $dc_admin_user_id and $dc_admin_project_id {
+ exec { 'update keystone admin assignment actor_id':
+ command => "sudo -u postgres psql -d keystone -c \"update public.assignment set actor_id='$dc_admin_user_id' from public.local_user where public.assignment.actor_id=public.local_user.user_id and public.local_user.name='admin'\"",
+ require => Exec['keystone bootstrap'],
+ }
+ -> exec { 'update keystone admin assignment target_id':
+ command => "sudo -u postgres psql -d keystone -c \"update public.assignment set target_id='$dc_admin_project_id' from public.project where public.assignment.target_id=public.project.id and public.project.name='admin'\"",
+ }
+ -> exec { 'update keystone admin user id':
+ command => "sudo -u postgres psql -d keystone -c \"update public.user set id='$dc_admin_user_id' from public.local_user where public.user.id=public.local_user.user_id and public.local_user.name='admin'\"",
+ }
+ -> exec { 'update keystone admin project id':
+ command => "sudo -u postgres psql -d keystone -c \"update public.project set id='$dc_admin_project_id' where name='admin'\"",
+ }
+ }
+
# Since the bootstrap is not guaranteed to execute on each run we
# use the below resources to make sure the current resources are
# correct so if some value was updated we set that.
--
2.34.1