| *** rosmaita has quit IRC | 03:04 | |
| *** markvoelker has joined #edge-computing-group | 04:41 | |
| *** bogdando has joined #edge-computing-group | 08:03 | |
| *** rosmaita has joined #edge-computing-group | 12:32 | |
| *** ianychoi has quit IRC | 12:49 | |
| *** kgiusti has joined #edge-computing-group | 12:54 | |
| csatari | #startmeeting weekly_edge_computing_group_call | 13:04 |
|---|---|---|
| openstack | Meeting started Thu Aug 9 13:04:06 2018 UTC and is due to finish in 60 minutes. The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:04 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:04 |
| openstack | The meeting name has been set to 'weekly_edge_computing_group_call' | 13:04 |
| csatari | #topic Roll call | 13:04 |
| csatari | #info Gergely Csatari | 13:04 |
| csatari | #topic Links | 13:07 |
| csatari | #link https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming | 13:07 |
| csatari | #link https://wiki.openstack.org/wiki/Edge_Computing_Group#Keystone | 13:07 |
| csatari | #topic Usage of Keystone federation on the field | 13:09 |
| csatari | #info StarlingX does not use Keystone federation at the moment. | 13:10 |
| csatari | #info Loss of connectivity between the client and the IdP can result in problems in case of Keystone federation. | 13:10 |
| csatari | #info StarlingX uses synchronisation of data. Now it moves towards a database synchronisation approach. Database synchronisation is half done. | 13:13 |
| csatari | #info The db replicaiton is done via an agent which is able to do schema transformation in case of diferent versions. | 13:15 |
| bogdando | o/ | 13:20 |
| csatari | #info The problem with API synchronisatio: 1) there is a table with revocation events which is populated by different actions, like password change 2) User ID-s and project ID-s are not synchronised (this is needed to enable the usage of Fernet keys generated remotely). | 13:20 |
| bogdando | for the DB replication topics, just wanted to point out some questions http://lists.openstack.org/pipermail/edge-computing/2018-August/000385.html | 13:20 |
| csatari | #info There is an activity to implement Galera spanning over multiple locations. | 13:21 |
| bogdando | I wish to know more of that agent which is able to do schema transformation in case of different versions, as well | 13:21 |
| csatari | bogdando: You can ask about it now and in the next 39 minutes here: https://zoom.us/j/671236148 | 13:21 |
| csatari | #info Galera is able to synch ~16 db-s. | 13:23 |
| csatari | #action csatari To do some analyzis on the listed concerns for the alternatives. | 13:31 |
| csatari | #info Mapping rules for Keystone federation can be static. | 13:32 |
| csatari | #info Singned SAML-s can be user only once and only for a specific SP. | 13:36 |
| csatari | Unscoped token can be reused, but can expire. | 13:37 |
| csatari | #info Unscoped token can be reused, but can expire. | 13:37 |
| csatari | #action Greg to get the StarlingX database replication design document to the Edge Computing Group wiki | 13:44 |
| csatari | #action csatari Update the wiki to have the two DB synch alternatives represented. | 13:46 |
| mbeierl | I thought this meeting was 1 hour later - is this the review of Dublin Edge Notes, or is this another meeting that I missed? | 13:47 |
| csatari | #topic Federation testing | 13:47 |
| csatari | mbeierl: This is the Keystone meeting. | 13:52 |
| mbeierl | csatari: ok, thanks | 13:52 |
| csatari | The review of Dublin notes starts in 8 mins. | 13:52 |
| csatari | #topic Closing | 13:56 |
| csatari | #info More meetings to come week after next week. | 13:57 |
| csatari | #info We will have a session in the PTG about Keystone. | 13:57 |
| csatari | #info We will use the same timeslot. | 13:58 |
| csatari | #info Thursday 15h-16h CET. | 13:58 |
| csatari | #endmeeting | 13:59 |
| openstack | Meeting ended Thu Aug 9 13:59:28 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-08-09-13.04.html | 13:59 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-08-09-13.04.txt | 13:59 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/weekly_edge_computing_group_call/2018/weekly_edge_computing_group_call.2018-08-09-13.04.log.html | 13:59 |
| csatari | #startmeeting review_of_dublin_edge_notes | 13: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. | 13:59 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| openstack | The meeting name has been set to 'review_of_dublin_edge_notes' | 14:00 |
| csatari | #topic Roll call | 14:00 |
| csatari | #info Gergely Csatari | 14:00 |
| mbeierl | #info Mark Beierl | 14:01 |
| csatari | Hellou | 14:02 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG | 14:03 |
| csatari | #info Wiki ^^ | 14:03 |
| csatari | #link AI-s: https://etherpad.openstack.org/p/Dublin-edge-notes-wiki | 14:03 |
| csatari | #link Previous notes: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/ | 14:04 |
| csatari | #topic Review of 5.3.2.15 Quotas receiver side | 14:05 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Quotas_receiver_side | 14:05 |
| csatari | Hah, the link is not okay. | 14:05 |
| csatari | #action csatari fix the links of the notes | 14:06 |
| csatari | Any comment to here? | 14:07 |
| csatari | #topic Review of 5.3.2.16 Progress monitoring | 14:07 |
| mbeierl | sorry - looks like I'm being pulled away | 14:07 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Progress_monitoring | 14:07 |
| csatari | Ah, okay. | 14:08 |
| csatari | I have an action item to remove new Kingbird, but I forgot to do it. | 14:11 |
| csatari | This is valid for th ewhole wiki. | 14:11 |
| csatari | mbeierl for how long are you pulled away? | 14:14 |
| mbeierl | #info 15 more minutes | 14:14 |
| csatari | Okay. | 14:15 |
| csatari | Ping me. | 14:15 |
| csatari | It looks like its only the two of us, so I will wait for you. | 14:15 |
| mbeierl | csatari: back now. Going to read the progress monitoring | 14:29 |
| csatari | okay | 14:30 |
| mbeierl | so, what do we mean by new Kingbird - saw that you said to remove it | 14:30 |
| mbeierl | and does StarlingX provide anything that can be used in this area? | 14:31 |
| csatari | Yes, in the Dublin discussions we planned to deveop Kingbird further. | 14:31 |
| csatari | https://wiki.openstack.org/wiki/Kingbird | 14:31 |
| 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:32 |
| 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 |
| mbeierl | aha | 14:33 |
| mbeierl | so StarlingX is the desired approach then? | 14:33 |
| csatari | The goal is not to make a decision on this in this wiki. Here we supposed cmopare the different alternatives. | 14:34 |
| mbeierl | ah ok. | 14:34 |
| csatari | And formulate "component independent" requirements. | 14:34 |
| csatari | It is an other discussion (and set of wiki pages) how to implement these. | 14:35 |
| mbeierl | I must admit, I am having a hard time getting to the heart of what StarlingX provides in their sync service. | 14:35 |
| csatari | There is a presentation what Greg showed us about this. | 14:35 |
| csatari | I can try to find it. | 14:36 |
| mbeierl | ok, thanks. | 14:36 |
| csatari | https://www.dropbox.com/s/ihczi2f5odccn6f/SynchFramework-DC-StarlingX.pptx?dl=0 | 14:36 |
| csatari | Okay, back to the review. | 14:37 |
| 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:37 |
| csatari | The idea there is that we can have a network of synch services. | 14:38 |
| csatari | More like a tree where there are edge cloud instances which are both receiving sync data and distributing it to others. | 14:38 |
| mbeierl | ok, and I realized now what is meant by services which are "under" it | 14:38 |
| mbeierl | so the direction and collection of data is directed | 14:38 |
| mbeierl | controlled, I mean. Ok, yes that is good then | 14:39 |
| csatari | okay | 14:39 |
| csatari | Moving forward. | 14:40 |
| csatari | #topic Review of 5.3.3.1 Operability data aggregation data provider part | 14:40 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_provider_part | 14:40 |
| mbeierl | list of active alarms is good, but should this section also include telemetry? | 14:41 |
| mbeierl | info about current usage, quotas, etc? | 14:41 |
| csatari | Yes, I will add them. | 14:41 |
| mbeierl | ok - this can feed into "something" than can help to make decisions about new service placement | 14:42 |
| csatari | #action csatari (5.3.3.1) add usage, quotas. | 14:42 |
| mbeierl | ie: the server with the GPU is getting full, we cannot place more GPU dependant services there | 14:42 |
| csatari | Orchestration. Yes. | 14:42 |
| csatari | But I will keep the "What else" there :0 | 14:44 |
| csatari | :) | 14:44 |
| mbeierl | yes | 14:44 |
| mbeierl | I am wondering - does each edge get connected directly, or are we aggregating this and collecting | 14:45 |
| mbeierl | like the previous section where there are services or edges "under" another edge? | 14:45 |
| mbeierl | or do we always assume this is the case? | 14:46 |
| csatari | That is the aggregation part in the next chapter. | 14:46 |
| csatari | So | 14:46 |
| mbeierl | ok | 14:46 |
| mbeierl | ah | 14:46 |
| csatari | #topi Review of 5.3.4 Operability data aggregation data aggregator part | 14:46 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_aggregator_part | 14:47 |
| csatari | #action csatari ( 5.3.4) fix the heading. | 14:47 |
| mbeierl | that seems a little different as it suggests control rather than collection of information | 14:47 |
| csatari | Control is the next chapter. | 14:48 |
| csatari | This is "Operability data aggregation data aggregator part" | 14:48 |
| csatari | But here we do not have the capablity to forward the collected data, so I thikn we should add that also. | 14:48 |
| mbeierl | ok | 14:49 |
| mbeierl | I read it as part of the same due to the size of the titles | 14:49 |
| csatari | Yes, that is my mistake. | 14:49 |
| mbeierl | that makes more sense then, thanks | 14:50 |
| csatari | #action csatari (5.3.4) Add the capability to forward the collected data. | 14:51 |
| csatari | #topic Review of 5.3.4.1 Remote control controlling part | 14:51 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Remote_control_controlling_part | 14:52 |
| csatari | Here we still miss th eoperations we would like to issue. | 14:52 |
| mbeierl | it is vague for sure | 14:52 |
| mbeierl | is the idea that any edge can 'proxy' or forward instructions to edges that are 'under' it? | 14:53 |
| mbeierl | If so, does the list then expand to all nova, glance, cinder, etc, APIs? | 14:54 |
| mbeierl | I may be asking questions that were already discussed, my apologies if so | 14:54 |
| csatari | Here we did not think about cascading, just some kind of remote control capability. | 14:55 |
| csatari | No worries. | 14:55 |
| csatari | Let's just record these questions and ask on the mailing list. | 14:56 |
| mbeierl | remote control of what? I guess this is what the operations that we should list is | 14:56 |
| csatari | remote control of an other edge cloud instance. | 14:56 |
| mbeierl | sorry, I meant remote control what parts? | 14:57 |
| mbeierl | does it come down to all possible APIs? | 14:58 |
| csatari | Ah, that is not figured out. | 14:58 |
| mbeierl | yes, that would be the 'list of operations' | 14:58 |
| csatari | #action csatari (5.3.4.1) Send a mail to the edge DL and ask what operations should be available. | 14:59 |
| csatari | Yes | 14:59 |
| csatari | Let me ask it on the DL. | 14:59 |
| mbeierl | sounds good. | 14:59 |
| csatari | #action (5.3.4.1) Ask edge computing DL if the remote control capability is direct or follows a cascading structure. | 15:00 |
| csatari | #topic Review of 5.3.4.2 Remote control receiving part | 15:01 |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Remote_control_receiving_part | 15:01 |
| csatari | This also depends on the questions you rased for the previous chapter. | 15:01 |
| mbeierl | yes, and depending on the actual operation, it might just be the OpenStack API that acts as its own receiving part. | 15:02 |
| mbeierl | For example, Nova for spawning a new VM... | 15:02 |
| csatari | Yes, this might be a null requirement for most of th ethings. | 15:02 |
| csatari | Maybe I add a note about this. | 15:02 |
| mbeierl | it is a requirement, just a null action as it might already be present :) | 15:03 |
| csatari | #action csatari (5.3.4.2) Add a note, that this requirement is already fullfilled for lots of operations. | 15:03 |
| mbeierl | it implies that there is a secure and authenticated connection from the control site to the receiving site | 15:03 |
| csatari | Yes | 15:04 |
| mbeierl | along with the associated firewall rules, etc, | 15:04 |
| csatari | Yes, this worh an other note :) | 15:05 |
| 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:05 |
| csatari | The listed questions I will ask on the Dl. | 15:06 |
| csatari | And we are done with the first round of review. | 15:06 |
| mbeierl | sounds good. | 15:06 |
| mbeierl | Congratulations! | 15:06 |
| csatari | 6 minutes over. | 15:06 |
| csatari | Thanks for participating. | 15:06 |
| mbeierl | not bad, considering we had a 20 minute break there | 15:06 |
| mbeierl | thanks for hosting! | 15:06 |
| csatari | #topic Closing | 15:06 |
| csatari | #info We are finished with the first round of reiview. | 15:07 |
| csatari | I plan to have an hour to spend on this wiki in the PTG, but no more IRC meetings. | 15:07 |
| csatari | #info No more IRC meetings will be organised. | 15:08 |
| csatari | #info There will be an hour long commenting session on the Denver II PTG. | 15:08 |
| csatari | #endmeeting | 15:08 |
| openstack | Meeting ended Thu Aug 9 15:08:34 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:08 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-08-09-13.59.html | 15:08 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-08-09-13.59.txt | 15:08 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-08-09-13.59.log.html | 15:08 |
| *** bogdando has quit IRC | 17:00 | |
| *** ricardoas has left #edge-computing-group | 17:05 | |
| *** ricardoas has joined #edge-computing-group | 18:42 | |
| *** kgiusti has left #edge-computing-group | 20:35 | |
| *** jonaspaulo has joined #edge-computing-group | 21:38 | |
| jonaspaulo | hi all | 21:39 |
| jonaspaulo | i have a doubt don't know if you can help me out | 21:40 |
| jonaspaulo | The goal was to have a central DC with multiple edge DCs but keeping just the Central DC with the redundant controller nodes in order to have just the computes and storage (probably HCI) on the edge DCs all managed with a single Openstack Installation. | 21:40 |
| jonaspaulo | I have checked nova cells which seems it could be used but not sure if this was enough | 21:40 |
| jroll | jonaspaulo: I'm working on pretty much that right now | 21:41 |
| jonaspaulo | nice | 21:41 |
| jonaspaulo | i watched some possible options like china mobile i think | 21:42 |
| jroll | the downside of this config is that the computes will need to talk to rabbit over WAN | 21:42 |
| jonaspaulo | but it seems that there isn't yet a ready to deploy solution as we speak | 21:42 |
| jonaspaulo | yes :/ | 21:42 |
| jonaspaulo | i have checked the trio2o also | 21:42 |
| jonaspaulo | but wasn't sure if it was maintained still | 21:42 |
| jonaspaulo | and the approach is different | 21:42 |
| jroll | I'm just now getting into looking at deployment automation, but agree, don't think anything does this out of the box right now | 21:42 |
| jonaspaulo | and i think it involves multiple OS | 21:42 |
| jonaspaulo | yep :/ | 21:43 |
| jroll | I think openstack-ansible will be close | 21:43 |
| jroll | (just from what I know about how ansible does things) | 21:43 |
| jonaspaulo | the single goal was to have lower power hardware and avoid the need of having to deploy controllers on every small dos | 21:43 |
| jroll | yep | 21:43 |
| jroll | and avoid a million API servers :) | 21:44 |
| jonaspaulo | i am more worried about scalability , security ,etc | 21:44 |
| jonaspaulo | idd | 21:44 |
| jroll | er, API endpoints | 21:44 |
| jonaspaulo | this for telco could use case/iot/mec etc | 21:44 |
| jroll | yep | 21:44 |
| jonaspaulo | i see that some big operators are doing their thing | 21:45 |
| jonaspaulo | but i was hoping i could use some openstack commercial distribution like RH OSP for this | 21:45 |
| jonaspaulo | gotta keep waiting them and do some testing on the nova cells I guess | 21:46 |
| jroll | I'm sure red hat would build it for you for the right amount of money :) | 21:46 |
| jonaspaulo | *then | 21:46 |
| jonaspaulo | ehe true | 21:46 |
| jonaspaulo | but it would always be a custom solution | 21:46 |
| jroll | this helped me think about the cells architecture for it https://www.openstack.org/videos/sydney-2017/adding-cellsv2-to-your-existing-nova-deployment | 21:46 |
| jonaspaulo | and for that I think there are already some that add on top of vanilla Openstack | 21:46 |
| jonaspaulo | oh yes i saw that today | 21:46 |
| jonaspaulo | thanks! | 21:46 |
| jonaspaulo | the china mobile one i think it is also good | 21:47 |
| jonaspaulo | because this is just a part of the puzzle | 21:47 |
| jonaspaulo | the VIM part | 21:47 |
| jroll | yep | 21:48 |
| jonaspaulo | the funnier part will also be orchestrate everything from VNFs on top of containers , VMs or bare metals, the small dc pods, etc | 21:48 |
| jroll | yeah, the user experience on top of the openstack bits will be interesting, we haven't thought that through much yet | 21:49 |
| jonaspaulo | i am already seeking some solutions that comply with MANO reference, but it misses some bits which are more present on the ONAP side it seems | 21:50 |
| jonaspaulo | well thanks for the talk :) i will stay around | 21:57 |
| jroll | :) | 21:58 |
| *** jonaspaulo has quit IRC | 22:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!