13:59:58 <csatari> #startmeeting review_of_dublin_edge_notes
13:59:59 <openstack> Meeting started Thu Aug  9 13:59:58 2018 UTC and is due to finish in 60 minutes.  The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:04 <openstack> The meeting name has been set to 'review_of_dublin_edge_notes'
14:00:05 <csatari> #topic Roll call
14:00:15 <csatari> #info Gergely Csatari
14:01:44 <mbeierl> #info Mark Beierl
14:02:04 <csatari> Hellou
14:03:32 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG
14:03:38 <csatari> #info Wiki ^^
14:03:51 <csatari> #link AI-s: https://etherpad.openstack.org/p/Dublin-edge-notes-wiki
14:04:09 <csatari> #link Previous notes: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/
14:05:12 <csatari> #topic Review of 5.3.2.15 Quotas receiver side
14:05:23 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Quotas_receiver_side
14:05:50 <csatari> Hah, the link is not okay.
14:06:10 <csatari> #action csatari fix the links of the notes
14:07:05 <csatari> Any comment to here?
14:07:47 <csatari> #topic Review of 5.3.2.16 Progress monitoring
14:07:56 <mbeierl> sorry - looks like I'm being pulled away
14:07:57 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Progress_monitoring
14:08:03 <csatari> Ah, okay.
14:11:48 <csatari> I have an action item to remove new Kingbird, but I forgot to do it.
14:11:57 <csatari> This is valid for th ewhole wiki.
14:14:37 <csatari> mbeierl for how long are you pulled away?
14:14:55 <mbeierl> #info 15 more minutes
14:15:01 <csatari> Okay.
14:15:05 <csatari> Ping me.
14:15:25 <csatari> It looks like its only the two of us, so I will wait for you.
14:29:58 <mbeierl> csatari: back now.  Going to read the progress monitoring
14:30:27 <csatari> okay
14:30:59 <mbeierl> so, what do we mean by new Kingbird - saw that you said to remove it
14:31:24 <mbeierl> and does StarlingX provide anything that can be used in this area?
14:31:31 <csatari> Yes, in the Dublin discussions we planned to deveop Kingbird further.
14:31:49 <csatari> https://wiki.openstack.org/wiki/Kingbird
14:32:57 <mbeierl> ya, I remember Kingbird, and thought it might have been abandoned.  So by "remove" is the decision to ignore it, or is the goal to revive it after all?
14:33:20 <csatari> And started to use the synch service new Kingbird, but then it turned out that StarlingX have a synch service (which is an evolution of Kingbird), so "new Kingbird" become both ambigous and product specific.
14:33:29 <mbeierl> aha
14:33:45 <mbeierl> so StarlingX is the desired approach then?
14:34:05 <csatari> The goal is not to make a decision on this in this wiki. Here we supposed cmopare the different alternatives.
14:34:35 <mbeierl> ah ok.
14:34:45 <csatari> And formulate "component independent" requirements.
14:35:20 <csatari> It is an other discussion (and set of wiki pages) how to implement these.
14:35:21 <mbeierl> I must admit, I am having a hard time getting to the heart of what StarlingX provides in their sync service.
14:35:51 <csatari> There is a presentation what Greg showed us about this.
14:36:04 <csatari> I can try to find it.
14:36:08 <mbeierl> ok, thanks.
14:36:41 <csatari> https://www.dropbox.com/s/ihczi2f5odccn6f/SynchFramework-DC-StarlingX.pptx?dl=0
14:37:15 <csatari> Okay, back to the review.
14:37:17 <mbeierl> so, do we need to split the progress monitoring into sending and receiving ends like the quota to help keep it clean.  As an example, I don't think we would want each edge to receive data about other edge locations.
14:38:10 <csatari> The idea there is that we can have a network of synch services.
14:38:40 <csatari> More like a tree where there are edge cloud instances which are both receiving sync data and distributing it to others.
14:38:44 <mbeierl> ok, and I realized now what is meant by services which are "under" it
14:38:58 <mbeierl> so the direction and collection of data is directed
14:39:14 <mbeierl> controlled, I mean.  Ok, yes that is good then
14:39:22 <csatari> okay
14:40:08 <csatari> Moving forward.
14:40:28 <csatari> #topic Review of 5.3.3.1 Operability data aggregation data provider part
14:40:38 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_provider_part
14:41:12 <mbeierl> list of active alarms is good, but should this section also include telemetry?
14:41:27 <mbeierl> info about current usage, quotas, etc?
14:41:42 <csatari> Yes, I will add them.
14:42:04 <mbeierl> ok - this can feed into "something" than can help to make decisions about new service placement
14:42:28 <csatari> #action csatari (5.3.3.1) add usage, quotas.
14:42:40 <mbeierl> ie: the server with the GPU is getting full, we cannot place more GPU dependant services there
14:42:51 <csatari> Orchestration. Yes.
14:44:27 <csatari> But I will keep the "What else" there :0
14:44:30 <csatari> :)
14:44:37 <mbeierl> yes
14:45:17 <mbeierl> I am wondering - does each edge get connected directly, or are we aggregating this and collecting
14:45:35 <mbeierl> like the previous section where there are services or edges "under" another edge?
14:46:36 <mbeierl> or do we always assume this is the case?
14:46:36 <csatari> That is the aggregation part in the next chapter.
14:46:37 <csatari> So
14:46:39 <mbeierl> ok
14:46:54 <mbeierl> ah
14:46:54 <csatari> #topi Review of 5.3.4 Operability data aggregation data aggregator part
14:47:02 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_aggregator_part
14:47:19 <csatari> #action csatari ( 5.3.4) fix the heading.
14:47:42 <mbeierl> that seems a little different as it suggests control rather than collection of information
14:48:22 <csatari> Control is the next chapter.
14:48:34 <csatari> This is "Operability data aggregation data aggregator part"
14:48:58 <csatari> But here we do not have the capablity to forward the collected data, so I thikn we should add that also.
14:49:27 <mbeierl> ok
14:49:43 <mbeierl> I read it as part of the same due to the size of the titles
14:49:54 <csatari> Yes, that is my mistake.
14:50:04 <mbeierl> that makes more sense then, thanks
14:51:06 <csatari> #action csatari (5.3.4) Add the capability to forward the collected data.
14:51:55 <csatari> #topic Review of 5.3.4.1 Remote control controlling part
14:52:06 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Remote_control_controlling_part
14:52:39 <csatari> Here we still miss th eoperations we would like to issue.
14:52:54 <mbeierl> it is vague for sure
14:53:26 <mbeierl> is the idea that any edge can 'proxy' or forward instructions to edges that are 'under' it?
14:54:20 <mbeierl> If so, does the list then expand to all nova, glance, cinder, etc, APIs?
14:54:42 <mbeierl> I may be asking questions that were already discussed, my apologies if so
14:55:29 <csatari> Here we did not think about cascading, just some kind of remote control capability.
14:55:32 <csatari> No worries.
14:56:22 <csatari> Let's just record these questions and ask on the mailing list.
14:56:36 <mbeierl> remote control of what? I guess this is what the operations that we should list is
14:56:56 <csatari> remote control of an other edge cloud instance.
14:57:58 <mbeierl> sorry, I meant remote control what parts?
14:58:10 <mbeierl> does it come down to all possible APIs?
14:58:15 <csatari> Ah, that is not figured out.
14:58:54 <mbeierl> yes, that would be the 'list of operations'
14:59:25 <csatari> #action csatari (5.3.4.1) Send a mail to the edge DL and ask what operations should be available.
14:59:27 <csatari> Yes
14:59:33 <csatari> Let me ask it on the DL.
14:59:36 <mbeierl> sounds good.
15:00:29 <csatari> #action (5.3.4.1) Ask edge computing DL if the remote control capability is direct or follows a cascading structure.
15:01:13 <csatari> #topic Review of 5.3.4.2 Remote control receiving part
15:01:23 <csatari> #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Remote_control_receiving_part
15:01:40 <csatari> This also depends on the questions you rased for the previous chapter.
15:02:13 <mbeierl> yes, and depending on the actual operation, it might just be the OpenStack API that acts as its own receiving part.
15:02:31 <mbeierl> For example, Nova for spawning a new VM...
15:02:40 <csatari> Yes, this might be a null requirement for most of th ethings.
15:02:56 <csatari> Maybe I add a note about this.
15:03:06 <mbeierl> it is a requirement, just a null action as it might already be present :)
15:03:33 <csatari> #action csatari (5.3.4.2) Add a note, that this requirement is already fullfilled for lots of operations.
15:03:59 <mbeierl> it implies that there is a secure and authenticated connection from the control site to the receiving site
15:04:18 <csatari> Yes
15:04:20 <mbeierl> along with the associated firewall rules, etc,
15:05:08 <csatari> Yes, this worh an other note :)
15:05:47 <csatari> #action csatari (5.3.4.2) Add a note that this implies that there is a secure and authenticated connection from the control site to the receiving site along with the associated firewall rules, etc,
15:06:06 <csatari> The listed questions I will ask on the Dl.
15:06:23 <csatari> And we are done with the first round of review.
15:06:26 <mbeierl> sounds good.
15:06:30 <mbeierl> Congratulations!
15:06:31 <csatari> 6 minutes over.
15:06:41 <csatari> Thanks for participating.
15:06:46 <mbeierl> not bad, considering we had a 20 minute break there
15:06:50 <mbeierl> thanks for hosting!
15:06:53 <csatari> #topic Closing
15:07:14 <csatari> #info We are finished with the first round of reiview.
15:07:46 <csatari> I plan to have an hour to spend on this wiki in the PTG, but no more IRC meetings.
15:08:02 <csatari> #info No more IRC meetings will be organised.
15:08:23 <csatari> #info There will be an hour long commenting session on the Denver II PTG.
15:08:34 <csatari> #endmeeting