14:18:28 <csatari> #startmeeting Review of Dublin edge notes 04
14:18:30 <openstack> Meeting started Thu Jun 14 14:18:28 2018 UTC and is due to finish in 60 minutes.  The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:18:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:18:34 <openstack> The meeting name has been set to 'review_of_dublin_edge_notes_04'
14:18:58 <csatari> #topic Roll Call
14:19:11 <csatari> #info Gergely Csatari
14:20:38 <csatari> #topic Correction of previous comments
14:21:00 <csatari> I've corrected the comments received so far.
14:21:47 <csatari> #info Status of the comments are maintained here: https://etherpad.openstack.org/p/Dublin-edge-notes-wiki
14:22:46 <csatari> There are quite big changes in some chapters.
14:23:21 <csatari> #info https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Example_of_Remote_and_Original_sites have big changes
14:24:31 <csatari> I'm not sure if we should recheck these during these meeting or just handle incoming comments if anyone has any.
14:24:58 <csatari> I would not like end up with 100 meetings just for reviewing this page ;)
14:25:00 <esarault> Not sure either, its aint like I'm going to argue over the KEystone and Glance points
14:25:55 <csatari> Lets just record this to the minutes and go on ;)
14:26:39 <csatari> #info Any comments to the already checked sections are welcome on edge-computing@lists.openstack.org
14:26:57 <csatari> Okay, lets jump into the requirements
14:27:49 <csatari> #topic Review of 5.3 Requirements
14:27:58 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements
14:28:56 <csatari> If no comments for that one sentence lets move.
14:29:09 <esarault> Yeah the outcome will depend heavily on Kingbird
14:29:31 <csatari> Skipping the empty chapters.
14:30:09 <csatari> Well, the point would be to define requirements to Kingbird or other projects.
14:30:31 <esarault> Ok then
14:30:44 <esarault> Dsicovery of data source section
14:30:59 <esarault> Are we expecting some sort of broadcast capabilities?
14:31:04 <csatari> #topic Review of 5.3.2.1 Discovering of data sources
14:31:09 <esarault> Or would this be reported to amaster entity
14:32:15 <csatari> I think we discussed a cascaded architecture.
14:32:40 <esarault> Some tiered reporting basically?
14:32:50 <esarault> X amount of nodes call back to their "masters"
14:33:00 <esarault> then those call back to theirs, until back to "root"
14:33:13 <csatari> When an edge cloud instance is "switched on" it should be able to find an other edge cloud instance which have the data.
14:33:22 <esarault> Ok
14:33:27 <csatari> yes
14:33:30 <esarault> Broadcasting?
14:33:34 <csatari> How it is done I have no idea ;)
14:34:04 <esarault> TherE's just things to keep in mind on that point. Not every network will allow broadcasting constantly
14:34:32 <esarault> Should be a notion of being able to "call back home" knowing where the home is supposed to be made when broadcasting on the network is not a viable route
14:34:37 <csatari> Should I add a note about this?
14:34:51 <esarault> If you believe it brings value please do so
14:34:57 <csatari> sure
14:35:07 <esarault> Taking for granted everyone is goign to allow broadcasting on their network is very unlikely
14:35:44 <csatari> #action csatari 5.3.2.1 add a note that broadcasting might not be possible in every network, so some alternative solution should be found.
14:36:39 <csatari> Any comments to this or to 5.3.1.1 An edge cloud site should be aware of its location?
14:37:13 <esarault> Nope, that's it for me
14:37:42 <csatari> #topic Review of 5.3.2.2 Registering for synchronisation
14:37:55 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Registering_for_synchronisation
14:37:59 <esarault> For Registering for synch, 1. there's a typo right before the word API, 2. I think this'll address the "call back home" capability so this looks good
14:38:36 <esarault> Home being the active edge instance(s)
14:39:16 <csatari> #action csatari 5.3.2.2 Fix reistration
14:39:32 <csatari> 2) okay
14:39:57 <csatari> #topic Review of 5.3.2.3 Advertise metadata data source service
14:40:12 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Advertise_metadata_data_source_service
14:40:40 <esarault> So here's a quesiton I have regarding authentication
14:41:17 <esarault> How can a node apply for registration if it isn't known in keystone
14:41:51 <esarault> Does Kingbird have a seperate list of authotized instances?
14:42:22 <esarault> which is then synchronized to Keystone if and only if approved
14:42:36 <esarault> or is there some Keystone implication when trying to register
14:42:44 <csatari> Here we are discussing OpenStack instances not nodes, but maybe that is irrelevant for the question.
14:43:10 <esarault> Well, let's see I have a new geo I want to join to the Edge Federation let's say
14:43:27 <esarault> And not just a node level
14:44:25 <csatari> I think the list of authrized instances should be dynamic.
14:44:28 <esarault> Do we expect the ability to add a new geo directly via Kingbird? How do the two Keystone instance sin each of those are synchronized? Which one takes over the other given the are now "one"?
14:45:56 <csatari> My thinking: 1) The new edge cloud insance finds its "master" edge cloud instance
14:46:33 <csatari> (It could either find Keystone first and ask for Kingbirds API or can find Kingbird directly)
14:47:09 <csatari> For this we will need "Advertise metadata data source service" in the "master"
14:47:33 <csatari> 2) The new edge cloud instance registers for synchrnoisation to the master
14:47:48 <csatari> For this we will need "Registering for synchronisation"
14:48:36 <csatari> Kingbird in the "master" edge cloud instance records the new edge cloud instance as a client for synchronisation and drops the current metadata to it.
14:49:15 <esarault> And my point is around this is where do we draw the line on what we expose of the existing environment for proper segregation of traffic until the new edge region is deemed "trustworthy and secure". Which service are we willing to expose, a discovery service running in Keybird or an active Keystone instance running production workloads that if compromised, could bring an entire
14:49:15 <esarault> region down. My understanding here is that Keybird would act as the gateway before allowing a new region to go talk to the active master Keystone
14:50:19 <csatari> Aham. Good point.
14:51:02 <esarault> I do agree on 1) and 2) but the security side of thing here is not to be underestimated.
14:51:18 <esarault> I see this as the first place I would go top onto to bring the region down
14:51:34 <esarault> *would go tap
14:51:43 <csatari> Should I add an authentication of the registering edge cloud instance requirement?
14:51:50 <esarault> I believe so
14:52:00 <esarault> This could be MAC adress filtering, IP ranges whitelisting
14:52:13 <esarault> The ability to define who's able to call to the edge instance
14:53:00 <csatari> I was thinking about some key exchange thing.
14:53:59 <esarault> Would work too
14:54:23 <csatari> Whitelist should be distributed to every "master" edge cloud instances.
14:54:24 <csatari> #action csatari Add a new requirement to authenticate the registering edge cloud instances.
14:54:41 <csatari> I can add these options and we can discuss it later.
14:54:50 <esarault> Sure thing
14:55:31 <csatari> Okay anything else for 5.3.2.3 Advertise metadata data source service ?
14:55:56 <csatari> #topic Review of 5.3.2.4 User management data source side
14:56:08 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#User_management_data_source_side
14:57:40 <csatari> #topic Next steps
14:58:01 <csatari> #info We will continue from 5.3.2.5 User management data receiver side
14:58:28 <csatari> I will start oranizing the next one.
14:58:40 <csatari> Sorry for being late.
14:59:06 <csatari> Should we keep doodling the time or should we go for a fixed time?
14:59:24 <csatari> For me doodling is a bit better due to my hectic calendar.
14:59:42 <csatari> But maybe a fixed time would result in better participation . . .
14:59:57 <esarault> Fixed time would be better it hink
15:00:14 <csatari> Okay, then let me do a doodle for a fixed time :)
15:00:15 <esarault> Otherwise you get these BS ad-hoc meetings that end up taking priority for all the wrong reasons
15:00:33 <csatari> okay
15:00:44 <esarault> I'm not one for sugar coating things :p
15:00:48 <csatari> #action csatari to organize a fixed time meeting for the reviews
15:01:16 <csatari> 😄
15:01:42 <esarault> Alright, see you next week, was a short but useful session ^^
15:01:52 <csatari> Thanks esarault for your comments anf thanks ildikov for lurking.
15:02:10 <csatari> I will not mis sthe first part of the next one ;)
15:02:13 <csatari> #endmeeting