15:01:38 #startmeeting massively_distributed_clouds 15:01:38 #chair ad_rien_ 15:01:38 #info agenda 15:01:38 #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (agenda: line 378 ) 15:01:39 Meeting started Wed Mar 29 15:01:38 2017 UTC and is due to finish in 60 minutes. The chair is ad_rien_. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:44 The meeting name has been set to 'massively_distributed_clouds' 15:01:45 Current chairs: ad_rien_ 15:01:46 ok let's start 15:02:01 as usual please add you name/nick in the pad 15:02:02 thanks 15:02:03 o/ 15:02:18 Hello all 15:02:27 o/ 15:02:28 Hi jfpeltier 15:02:41 o/ 15:02:43 o/ 15:02:49 Hi o/ 15:03:40 #topic announcements 15:03:53 So from my side two important info: 15:04:00 o/ 15:04:03 First we have a slot for our face to face meeting in boston 15:04:24 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/18671/fogedgemassively-distributed-clouds-working-group face to face meeting in Boston (please book the slo) 15:04:59 Hi - Jamey here 15:05:10 I asked this slot because it will be come after the different presentations that will deal with multi sites/massively distributed / Fog /Edge …. stuffs 15:05:17 so this is I think rather good 15:05:20 Second announce: 15:05:37 We should agree on submitting a topic to the forum call 15:05:57 the link is in the pad. 15:06:24 Curtis, chairman of the NFV working group has already submitted something this morning and contacted us to propose to join his proposal 15:06:29 so the question is rather clear 15:06:37 Do you want to submit another topic ? 15:07:18 #link https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge (Massively Distributed WG, braimstorming on possible topics for the forum) 15:07:30 so I think we can spend 5 minutes (no more) on that question ? 15:08:16 If I'm correct this pad is rather ''empty'' in the sense that unless I am mistaken we did not get so many inputs ? 15:08:24 so I think we have two questions : 15:08:38 My thought in general on Forum topics - and spcific I think to our group here - is you shoudl have a Forum topic to match any presenation you are giving 15:08:56 1./ Does anyone know what is expected from the forum view point? and 2./ Does it make sense to submit something? 15:09:30 So I think we can join the Curtis proposal 15:09:48 #link http://forumtopics.openstack.org/cfp/details/58 (NFV WG forum proposal) 15:09:50 So one or more on Fog/Edge is appropraite and even necessary to explain the work going on here 15:10:09 Perhaps one on each of the Fog/Edge cases of the group 15:10:36 Sorry if I'm going off in a strange direction - but I can't stop 15:10:38 It may overlap the Curtis proposal/ 15:11:44 In essence the Forum topic will be like a way to debate that specific area - think of it as a room and a time to have face to face 15:11:45 FYI I just copied/pasted the proposal of curtis in the pad 15:11:55 Can someone explain me, what a forum is exactly? 15:11:59 yes but how many people are expected ? 15:12:15 I mean having an informal discussion with 20/25 people is something which is already tedious 15:12:25 so if you get 100 persons, I don't know what we can expect ? 15:12:48 rcherrueau: https://wiki.openstack.org/wiki/Forum 15:12:55 kgiusti: thanks 15:13:01 If you get 100 person, maye the outcome will be to create multiple subgroups. 15:13:05 Keeping in mind the proposal of Curtis, maybe we can make a proposal on the AMQP/oslo.messaging 15:13:06 ? 15:13:31 Yes - from the Curtis run Telco NFV sessions in Barcelon - will get 25+ on this topics with majority being "interested" 15:13:34 paul-andreraymon: good point. Who is going to propose to make subgroups, I guess you would need moderators 15:13:52 ok 15:13:58 So let's try to move forward 15:14:17 1./ we have the curtis proposal (that explicitly mentions the Massively Distributed WG) 15:14:42 2./ we can make another proposal related to the massively distributed but in that case we should position ourself w-r-t the Curtis proposal 15:14:51 But still - being scared the discussion will be slow/often interrupted is probably not a good reason to abandon it entirely 15:14:56 3./ we can make something more specifics like the AMQP discussion? 15:15:06 @adrien #2 - Agreed 15:16:01 Guys, who will be interested by moderating a discussion around the AMQP debate (that has been launched last week)? 15:16:12 I think this can be valuable 15:16:30 more precisely this can make sense to try to clarify why we have folks that deal with RMQ 15:16:40 why other try to push ZMQ 15:16:50 and why Monasca has been built on top of Kafka 15:17:01 and finally what can be the place of Qpid 15:17:31 From my point of view this makes sense but it requires times to prepare the discussion (with appropriate content) 15:17:37 ad_rien_: I am OK to be part of that, but we should push agreed on the topic first. 15:17:48 we should be* 15:17:58 @ rcherrueau - To try to answer in 1 line: Forum is the replacement for previous Design Summit - more emphasis on getting both User/Operators gettign their input and collaboration going but also together with the Project Teams. Need to have the Operators/Users be specifying the important topics. 15:17:59 ad_rien_: we'd need participation from the other oslo.messaging cores I would think. 15:18:00 I'm unfortunately already involved in different presentations for Boston, So I would rather prefer to not be to overwhelmed. 15:18:32 kgiusti: agree but proposing something is the first step. 15:18:34 I think 15:18:43 Logistically it is a block of rooms for 3 days straight, you look up the schedule and go to the next one you are most interested in. 15:18:55 wo can make a draft (deadline is next sunday)? 15:19:11 jamemcc: OK thanks 15:19:26 But AMQP what can be discussed? 15:19:50 No proposal? 15:20:07 ok seems not 15:20:10 ad_rien_: In my opinion there's not a consistent story regarding the use of backends 15:20:31 kgiusti: can you elaborate a bit more ? 15:20:33 please 15:20:49 ad_rien_: e.g. - when asked "which backend should I use" there's no official guidelines 15:20:55 exactly 15:21:20 but there are efforts through the architecture WG to try to identify common tools 15:21:21 ad_rien_: we talked about this at the last summit, but there were not enough interested parties to come to a conclusion 15:21:52 Maybe if we suceed to get sufficient content we can animate a discussion and finally make progress 15:22:06 ad_rien_: simply getting a consensus regarding the purpose of the different backends would be ideal 15:22:15 is there a discussion to be had on a reference AMQP architecture for Massively distributed? 15:22:28 yes paul-andreraymon 15:22:33 at least we want to identify requiremetns 15:22:47 ad_rien_: so I can propose to the oslo folks that we're planning some discussion around that in particular 15:22:51 in order to be able to investigate whether this brick ou this one satisfies the requirements 15:22:57 kgiusti: great 15:23:04 can you come back to us shortly 15:23:20 so if it makes sense to submit something we can do it by sunday 15:23:46 (even better, if you can come with a proposal like the curtis one but that focus on the oslo.messaging question, it would be perfect) 15:24:00 Then we need to identify moderators that can help you on this action. 15:24:06 kgiusti: what do you think? 15:24:08 ok 15:24:11 Great thanks 15:24:20 ok so briefly two more minutes 15:24:26 kgiusti: let me know if you need help 15:24:31 are there any other news from your side? 15:24:44 or we can move to the next topic 15:24:45 ? 15:25:09 ? 15:25:17 ok so let's move to the next topic 15:25:21 #topic AMQP 15:25:46 Can we have an overview of the current discussion? I saw several emails (thanks BTW ;)) 15:25:50 rcherrueau: kgiusti ? 15:25:56 Let me try to sum up discussions we started around this topic 15:27:06 So we start an informal discussion with the aim to get a good understanding of the specification of oslo_messaging 15:28:14 so much works :)? 15:28:55 most of the conversation is to define the aspects of the high level API 15:28:57 So we try to categorise the different oslo_messaging feature (ie. rpc.call, rpc.cast, notify ...) regarding to three properties that commonly arise when you wanna compare messaging paradims 15:29:09 rcherrueau: +1 15:29:18 ok cool 15:29:52 Lemme put the three properties into the pad 15:30:06 (let's consider that we have five minutes for getting a summary: what has been discussed and what are plans for the next two weeks) 15:30:28 see line 410 15:32:02 The aim of this work is the following: we need to correctly understand what oslo_messaging is supposed to do, before discussing/understanding the different backend (RMQ/ZMQ/QPid ...) 15:32:40 ok 15:33:54 (mabderrahim: do you know whether monasca is using oslo.messaging ? probably a naive question but in case…., I know it leverages kafka but I would like to know whether it is using kafka through oslo.messaging or any other API?) 15:33:59 ad_rien_: I could write a sum up of the discussion for the next meeting if you want. 15:34:05 yes please 15:34:29 We have had a good start on functional overview. It would be good if we could get some data on which features are most used. That discussion did not happen yet. 15:34:31 #action rcherrueau prepare a summary for the next meeting (i.e. put it in the pad thanks) 15:34:31 Monasca uses Kafka directly 15:34:42 mabderrahim: thanks 15:34:46 it does not rely on an other api 15:34:52 welcome 15:35:14 paul-andreraymon: good point 15:35:33 How could we move forward on that? any suggestions? 15:35:34 Maybe ENOS (that I hope will be discussed later on) can help us to get such information 15:35:43 paul-andreraymon: yes you are. I wanna run some static analysis of the code for that. 15:35:51 rcherrueau: do you agree? 15:36:07 ad_rien_: yep 15:36:15 +1 15:36:37 ok so, leveraging the overview rcherrueau is going to do, it would be great to invite the oslo.messaging core developers and get their feedbacks 15:36:46 ok anything else on that point ? 15:37:07 I'll reach out and invite them 15:37:13 ok thanks 15:37:25 so maybe we can have a brief overview regarding the AMQP stresser 15:37:37 jfpeltier: can you give us a few elements regarding the stresser ? 15:38:08 yes tests are still in progress, I plan to do a presentation tomorrow with Abdelhadi 15:38:44 For the time being we don't manage to separate stress to the Rabbimq controller from stress on the newtworking part 15:38:45 ok is the code on github ? 15:38:59 yes I send link 15:39:09 jfpeltier: in what forum are you making this presentation? 15:39:20 https://github.com/Carroll/osnoise 15:39:24 sorry paul-andreraymon 15:39:29 Presentation is slides/discussion 15:39:30 an internal meeting we have tomorrow 15:39:48 we will push the links toward slides in the pad 15:39:56 so everyone can see them by the next meeting 15:40:03 Thanks! 15:40:16 (sorry for the missunderstandings) 15:41:08 #link https://github.com/Carroll/osnoise AMQP stresser tools (developed by OL) 15:41:22 the good news is that we manage to put a lot of stress on amqp contrller 15:41:49 ok 15:42:13 the bad news are that it may not be very representative of real massively distributed solution where stress is not put on a single component 15:42:33 (nor link) 15:42:40 I hope we wil be able to discuss a bit more this tool next time (and see how it can be integrated in a framework link Enos) 15:42:49 we want to discuss this in the presentation 15:42:53 ok 15:43:02 so I propose to move forward 15:43:09 if there is no more question on that point. 15:43:10 ? 15:43:29 seems not 15:43:31 ok 15:43:32 #topic ECOMP 15:43:47 Jamey put the link in the etherpad for the doodle 15:44:22 Please all if you are interested by the presentation 15:44:28 fit the doodle by 15:44:42 Thanks Adrien 15:44:48 let's say by friday ? 15:45:03 Good so I can schedule by Monday Morning 15:45:14 jamemcc: do you think it would be possible for you to extend the doodle now so that every one can fill it asap 15:45:15 ? 15:45:15 UST 15:45:59 YEah - I did - shoudl show through APril 5 now 15:46:23 ok thanks 15:46:40 ok so I propose we move forward 15:46:47 unless there is particular question? 15:46:52 regarding ECOMP? 15:47:16 Can we get a copy of the slides ahead of the presentation? 15:47:30 Makes sense - will try 15:47:35 thanks 15:47:59 #jamemcc will send slides before the presentation 15:48:08 #action irc://irc.freenode.net:6667/#jamemcc will send slides before the presentation 15:48:36 #all please fill the doodle if you are interested by taking part in the discussion on ECOMP (please see the pad line 427) 15:48:48 #topic ENOS 15:49:01 @msimonin @rcherrueau ? 15:49:04 pleas go aehad 15:49:23 OK, lemme start with the link of the procjet 15:49:31 #link https://github.com/BeyondTheClouds/enos 15:49:56 So Enos is a tool for Performance analysis of OpenStack 15:50:08 #link https://www.openstack.org/summit/boston-2017/summit-schedule/events/17952/toward-fog-edge-and-nfv-deployments-evaluating-openstack-wanwide (Enos Boston presentation) 15:50:44 it lets you deploy an OpenStack, then run some bench and finally get Network/CPU/RAM usage 15:51:33 Enos comes with a DSL, so that you can easily describe the topology of your OpenStack 15:52:31 Actually we support 3 providers to deploy OpenStack 15:53:12 g5k and chameleon that are research testbed 15:53:29 #link https://www.chameleoncloud.org Chameleon 15:53:31 and vbox (for development) 15:53:50 #link https://www.grid5000.fr/mediawiki/index.php/Grid5000:Home Grid'500 testbed 15:54:22 The fun part is that chameleon is operate through an OpenStack so with Enos you can deploy, more generally, OpenStack over OpenStack 15:54:36 and then run bench, ... 15:55:11 FYI, chameleon provides both baremetal and vm resources 15:55:45 We recently integrate osprofiler that produces traces of your OpenStack 15:56:37 So, I hope we could use this to understand better interaction that use the message bus. 15:57:06 ad_rien_: I don't know if we have time for question? 15:57:19 I think we should conclude 15:57:27 so please add content directly in the pad 15:57:34 #topic opendiscussion 15:57:47 (sorry for being restrictive but we run out of time) 15:58:06 so I just added a new etherpad for our face to face meeting in Boston and more generally to try to apply a divide and conquer strategy 15:58:13 so you will see for instance in 15:58:26 #link https://etherpad.openstack.org/p/Massively_distributed_wg_boston_summit face to face meeting in Boston 15:58:47 that I propose to list all rpesentations/sessions that make sense for our WG 15:59:23 by this way we will be able to try to cover/attend most of the presentations and then exchanges during our face to face meeting that is scheduled on Wednedsay afternoon 15:59:31 I will give your more details next time 15:59:38 Thanks all for joining the meeting 15:59:44 let's continue by mail or by the pad 15:59:44 thanks 15:59:52 thanks 15:59:53 #endmeeting