14:01:17 #startmeeting review_of_dublin_edge_notes 14:01:18 Meeting started Thu Jun 28 14:01:17 2018 UTC and is due to finish in 60 minutes. The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:21 The meeting name has been set to 'review_of_dublin_edge_notes' 14:01:27 #topic Roll Call 14:01:38 #info Gergely Csatari 14:02:19 hello again 14:02:38 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG 14:02:52 i will have to drop in 15 min 14:03:05 Hah, better to hurry , then :) 14:03:13 +1 14:03:16 #topic Housekeeping 14:03:31 I did had one concern on federation. 14:03:42 #info We continue from 5.3.2.5 User management data receiver side 14:03:51 say we have edge/core that is vmware based, say VIO 14:03:56 Okay, What is it? 14:04:02 o/ 14:04:10 And and far edge is openstack on baremetal. 14:04:33 how does keystone fderation worrk? 14:05:29 The VIO OpenStack should be configured to be an Identity provider 14:05:55 While the far edge Keystone should be configured to use the remote Identity providesr. 14:06:14 VIO will use vSsphere for platform and its identity management. Keystone is just a shim on top of it. 14:06:51 Aham. We should ask this from Ketstone guys. 14:07:05 #topic Keystone architectures 14:07:10 if kesyotone can use remote ID provider then it will work. probably with local cache for disconnect periods. 14:07:18 thanks 14:07:44 #info VIO Keystone is only a shim layer on top of vSphere. Is it possible to configure this as an Identity provider? 14:08:02 I will ask vmware folks 14:08:15 I will add this as a question to https://wiki.openstack.org/wiki/Keystone_edge_architectures 14:08:22 Okay, please report back the result. 14:08:54 #action csatari to add this question to https://wiki.openstack.org/wiki/Keystone_edge_architectures#Several_keystone_instances_with_federation_and_API_synchronsation 14:09:41 #topic Review of 5.3.2.5 User management data receiver side 14:10:19 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#User_management_data_receiver_side 14:11:18 I think we should add the option to create shadow users here as it is done with K2K federation. 14:11:44 #action csatari 5.3.2.5 Add the possibility to use shadow users. 14:12:32 csatari: Does all ACL associated with user come along with shadow user? 14:12:52 I think not. 14:13:21 Shadow user is created by rules defined on the far side. 14:13:30 So things like object store permissions etc could be an issue at the edge node? 14:14:06 According to my understanding these can be set using these rules. 14:14:53 Mapping rules: https://docs.openstack.org/keystone/latest/advanced-topics/federation/federated_identity.html#mapping-combinations 14:14:57 So master keystone has to create mappings that will be used for creating shadow users? Something along those lines? 14:15:19 csatari: tx 14:15:21 Nope, the mapping is done in the edge Keystones 14:15:52 need to drop 14:16:08 But the best is to ask it on the DL (any of them) from Keystone guys. 14:16:10 Okay 14:16:13 See you. 14:17:17 Any more comments to 5.3.2.5 ? 14:17:55 #topic Review of 5.3.2.5 User management data receiver side 14:18:04 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#User_management_data_receiver_side 14:18:34 Here we should also mention the sahdow users case. 14:19:16 Hah! we just discussed this. 14:19:41 #topic Review of 5.3.2.6 RBAC data source side 14:21:26 #info Can we totally rely on K2K federation here or do we still need to synchronise data? 14:22:34 I will ask in mail. 14:24:19 #topic Review of 5.3.2.7 RBAC data receiver side 14:24:46 #info Same goes to here as for 5.3.2.6 14:26:07 I just saw esarault -s mail. 14:26:32 Am I doing a lonely review here? 14:30:30 I think I've lost quorum, so I stop here with the review. 14:30:38 #topic End meeting 14:31:07 #info We will continue from 5.3.2.8 VM images source side 14:32:03 #info Next meeting is on 2018.07.05 16:00 CET on #edge-computing-group 14:32:15 #endmeeting