5afd5f90b2
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 change added a patch to keystone puppet manifest, that updates 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 retrieving central registry credential failure when platform-integ-apps is reapplied. Change-Id: I509a06b4b810620a1b3648837726f7f2771162a5 Closes-Bug: 1851247 Signed-off-by: Andy Ning <andy.ning@windriver.com>
64 lines
3.0 KiB
Diff
64 lines
3.0 KiB
Diff
From 60f023e20c7e1f98d1f71fb04e829a3ff0477f65 Mon Sep 17 00:00:00 2001
|
|
From: Andy Ning <andy.ning@windriver.com>
|
|
Date: Mon, 4 Nov 2019 20:20:28 -0500
|
|
Subject: [PATCH 1/1] update Barbican admin secret's user/project IDs during
|
|
bootstrap
|
|
|
|
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>
|
|
---
|
|
manifests/init.pp | 18 ++++++++++++++++++
|
|
1 file changed, 18 insertions(+)
|
|
|
|
diff --git a/manifests/init.pp b/manifests/init.pp
|
|
index 7bb0094..421259c 100644
|
|
--- a/manifests/init.pp
|
|
+++ b/manifests/init.pp
|
|
@@ -791,6 +791,8 @@ class keystone(
|
|
$rabbit_port = $::os_service_default,
|
|
$rabbit_userid = $::os_service_default,
|
|
$rabbit_virtual_host = $::os_service_default,
|
|
+ $dc_admin_user_id = undef,
|
|
+ $dc_admin_project_id = undef,
|
|
) inherits keystone::params {
|
|
|
|
include ::keystone::deps
|
|
@@ -1311,6 +1313,22 @@ running as a standalone service, or httpd for being run by a httpd server")
|
|
subscribe => Anchor['keystone::dbsync::end'],
|
|
tag => 'keystone-exec',
|
|
}
|
|
+
|
|
+ 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-manage 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'\"",
|
|
+ }
|
|
+ }
|
|
}
|
|
|
|
# WRS: Now that the keystone service has started,
|
|
--
|
|
1.8.3.1
|
|
|