14:02:17 <csatari> #startmeeting review_of_dublin_edge_notes 14:02:18 <openstack> Meeting started Thu Jul 12 14:02: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:02:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:21 <openstack> The meeting name has been set to 'review_of_dublin_edge_notes' 14:02:38 <csatari> #topic Roll Call 14:02:45 <dpaterson> here 14:02:48 <csatari> #info Gergely Csatari 14:03:04 <esarault> #info Eric Sarault 14:03:29 <dpaterson> #info David Paterson 14:04:28 <csatari> #topic Action items 14:05:03 <csatari> #link https://etherpad.openstack.org/p/Dublin-edge-notes-wiki 14:05:15 <csatari> I had no time to work on them this week. 14:05:28 <csatari> Next week will be better :) 14:05:36 <csatari> #info No progress 14:05:49 <esarault> Don'T be too harsh on yourself ;) 14:06:10 <csatari> I'm doing my best :) 14:06:20 <csatari> Okay, lets jump to the review part. 14:06:51 <csatari> #topic Review of 5.3.2.10 Flavors source side 14:07:07 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Flavors_source_side 14:08:15 <esarault> Nothing to add 14:08:25 <csatari> If no comments lets move forward (I already have an action to generalize the synch service) 14:08:47 <csatari> #topic Review of 5.3.2.11 Flavors receiver side 14:09:01 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Flavors_receiver_side 14:10:01 <csatari> Moving on 14:10:24 <csatari> #topic Review of 5.3.2.12 Projects source side 14:10:36 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Projects_source_side 14:10:49 <csatari> Here I talk about Quotas sometime. 14:11:03 <csatari> That should be changed to Project. 14:11:36 <csatari> #action (5.3.2.12) Change Quotas to Projects. 14:13:00 <csatari> Can we have some inconsistency when projects are copied? 14:14:44 <csatari> Most probably not, but I will check what data is stored in a project. 14:15:50 <dpaterson> Sorry but when you say copy project are you referring to Keystone Federation creating shadow projects and users? 14:15:51 <csatari> #action (5.3.2.12) Check if the data in a project can be inconsistent during the synchronisation (e.g.: if there are uuid-s there which are valid only olcally) 14:17:10 <csatari> No, in this case there is a separate synchronisastion service doing the creation of projects and users. 14:17:33 <csatari> And yes, I think we should describe the Keystone federation case also. 14:17:51 <csatari> However these two alre alternatives on some level. 14:18:36 <dpaterson> #link https://wiki.openstack.org/wiki/Keystone_edge_architectures#Several_keystone_instances_with_federation_and_API_synchronsation 14:19:02 <dpaterson> csatari: that's the topic? 14:19:35 <csatari> yes 14:20:59 <csatari> What is described in the Dublin edge notes is "2.4 Keystone API Synchronization & Fernet Key Synchronization" without the fernet keys. 14:21:37 <csatari> And the question is if we should also describe "2.1 Several keystone instances with federation and API synchronsation" as an alternative approach. 14:21:56 <csatari> Or totally replace the API Synchronisation way. 14:22:21 <dpaterson> csatari: looking, I was in Dublin but not in Edge track until just recently 14:23:01 <csatari> In my personal opinion there will be no single option selected for these different issues, so the best would be to describe both of these alternatives in the wiki. 14:23:27 <csatari> We can always delete if an idea turns out to be non working. 14:26:21 <csatari> #action Add Requirements for the "2.1 Several keystone instances with federation and API synchronsation" option from https://wiki.openstack.org/wiki/Keystone_edge_architectures#Several_keystone_instances_with_federation_and_API_synchronsation 14:28:28 <csatari> This ^^^ will affect all Keystone metadata related requirements. My plan is to describe a separate set of requirements for both of these options. 14:28:33 <dpaterson> csatari: The Keyston sycronization service you are calling out is referring to the starlingx syncronization serivce correct? 14:28:57 <csatari> StarlingX synsh service is one implementation of it. 14:29:41 <csatari> When we defined it we did not know that WindRiver implemented it and we did not know that it will be open sourced under the name StarlingX. 14:30:00 <csatari> We wanted to develop Kingbird further or start a new project to do this. 14:30:16 <csatari> StarlingX synch service is also based on Kingbird by the way. 14:30:22 <dpaterson> #csatari: From Monday's Edge meeting it looks like starlingx syncronization service is pretty dependent on starlingx specific bits 14:30:44 <csatari> Yes. 14:30:53 <dpaterson> #csatari: and kingbird looks pretty inactive 14:31:01 <csatari> Yes. 14:32:08 <csatari> But I would not like to drop the idea of an independent synch service. 14:32:12 <dpaterson> csatari: This might sound old school but was using distributed LDAP discussed as a viable model? 14:32:34 <csatari> No it was not discussed. 14:32:57 <csatari> In some meeting Keysone people stated that LDAP is not an IDP, but something else. 14:33:06 <csatari> This is all what I remember :) 14:33:20 <dpaterson> csatari: with LDAP master/replicas you would get eventual consistancy for free 14:33:54 <dpaterson> So instead of keystone database for auth realm use ldap (apache directory or openldap) 14:34:04 <csatari> And can Keystone use LDAP as a backend database? 14:34:08 <dpaterson> Yes 14:34:16 <dpaterson> always been supported 14:34:30 <dpaterson> as far as I know 14:35:41 <csatari> And can we synch all needed Keystone data with this method? 14:36:00 <dpaterson> csatari: could solve a lot of the discussion points without the need of an external syncronization service. 14:36:04 <dpaterson> That I am not sure about 14:37:03 <csatari> Okay. Let's add it to the Keystone alternatives list and start a discussion on the mailing lists. 14:37:17 <dpaterson> I will take an AI to see what support there is, if it's auth only or if Projects/ACL/RBAC are part of ldap schema or does that data still have to live in relational database 14:38:07 <dpaterson> It may allow auth only and depend on keystone database for everything else, not sure. 14:38:13 <csatari> #action Add an alternative to the Keystone alternatives wiki for Keystone with distributed LDAP backend. 14:38:21 <csatari> Okay, thanks. 14:38:54 <csatari> #action dpaterson to check what support there is, if it's auth only or if Projects/ACL/RBAC are part of ldap schema or does that data still have to live in relational database 14:39:34 <csatari> #action Start a mail discussion about the Keystone with distributed LDAP backend alternative 14:39:59 <dpaterson> csatari: and under Keystone database replication, is this specifically Galera? Do we want to call out specific relational database distros that might work? 14:40:54 <csatari> The description is technology agnostic, but if we can add in a note database distros what can actually do the work that is usefull information. 14:43:08 <dpaterson> #link https://www.researchgate.net/publication/4284466_Enhancing_Edge_Computing_with_Database_Replication 14:43:15 <dpaterson> from 2007 14:44:38 <csatari> :) 14:45:46 <csatari> #topic Review of 5.3.2.13 Projects receiver side 14:46:02 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Projects_receiver_side 14:49:00 <csatari> Moving on. 14:49:21 <csatari> #topic Review of 5.3.2.14 Quotas source side 14:49:27 <dpaterson> csatari: an issue with syncronization service vai API is that it needs to be in lockstep with any schema changes 14:49:45 <csatari> #link https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dublin_PTG#Quotas_source_side 14:50:11 <csatari> With API changes not (db) schema changes. 14:50:35 <dpaterson> Yes, you are right 14:50:43 <csatari> the issue with db synchronisation is that it should clockstep db schema changes. 14:51:18 <csatari> An independent syncronisation service can support several versions of API-s. 14:51:19 <dpaterson> yup 14:51:35 <csatari> Even several VIM-s, but let's not go that far now. 14:52:54 <csatari> Okay, lets start the wrapup. 14:53:08 <csatari> #topic Wrapup 14:53:46 <csatari> #info Next Thursday we will have the Keystone testing meeting in the same time as this meeting, so we will skip the review. 14:54:13 <csatari> #info Next meeting is 26.07.2018 16 CET 14:54:44 <csatari> #info We will contiue from 3.2.15 Quotas receiver side 14:56:00 <csatari> #info I try to organize a meeting to discuss about https://wiki.openstack.org/wiki/Image_handling_in_edge_environment but that will be in a different timeslot than this one as we are parallel to the Glance meeing and I would like to invite Glance experts. 14:56:16 <csatari> That is it for today. 14:56:23 <csatari> Have a nice day. 14:56:26 <csatari> #endmeeting