15:00:37 <ad_rien_> #startmeeting massively_distributed_clouds
15:00:37 <ad_rien_> #chair ad_rien_
15:00:37 <ad_rien_> #info agenda
15:00:37 <ad_rien_> #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017
15:00:43 <openstack> Meeting started Wed Feb  1 15:00:37 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:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'massively_distributed_clouds'
15:00:47 <openstack> Current chairs: ad_rien_
15:01:11 <serverascode> hello :)
15:01:13 <ad_rien_> menthos, denaitre, msimonin, ansmith, rcherrueau, hcoullon
15:01:17 <ad_rien_> guys ?
15:01:19 <kgiusti> hi
15:01:22 <Menthos> Hey o/
15:01:22 <dsantoro> hello
15:01:23 <ad_rien_> Hi serverascode
15:01:26 <ansmith> o/
15:01:37 <ad_rien_> #info agenda
15:02:01 <ad_rien_> #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 line 136
15:02:33 <ad_rien_> OK let's way a couple of seconds, some folks from Orange might join
15:02:35 <ad_rien_> us
15:02:36 <denaitre> hi o/
15:03:32 <ad_rien_> Ok, before starting may I ask you to add items in the open discussions if there are particular points you would like to discuss, thanks
15:03:36 <ad_rien_> so let's start
15:03:54 <ad_rien_> #topic  Announcement
15:04:44 <ad_rien_> Some new achievements regarding the ENOS framework as you may have seen on the pad, in particular a Vagrant driver that enables you to test Enos on your machine and a new official docs
15:04:52 <ad_rien_> #link http://enos.readthedocs.io/en/latest/
15:05:24 <ad_rien_> Second point is about the proposal for Boston, we are going to submit with the University of Chicago
15:05:44 <ad_rien_> #link https://pad.inria.fr/p/sfBMUvWOpKtmfXT8 if you want to give a look
15:05:57 <ad_rien_> and that's all from the Inria side.
15:06:20 <ad_rien_> Are there news from your side guys that you would like to share?
15:06:48 <ad_rien_> serverascode: some news regarding the NVF Working group that can be shared here?
15:07:26 <ad_rien_> ok seems not :-)
15:07:35 <serverascode> sure, if you mean that we are working on a presentation for the summit on multi-site/cloud?
15:07:39 <ad_rien_> yes ?
15:08:00 <serverascode> ok :) Yup we are working on a joint presentation on an overview of multi site, cloud, distributed etc
15:08:01 <ad_rien_> did you make progress? Unless I am mistaken, I didn't see any proposal?
15:08:17 <serverascode> I am writing the abstract today for the summit proposal
15:08:24 <serverascode> and will send it out to any intrested parties
15:08:29 <serverascode> *interested
15:08:35 <serverascode> it'll be on an etherpad
15:08:39 <ad_rien_> serverascode ok sound goods
15:09:18 <ad_rien_> #action serverascode will share an etherpad regarding the NFV WG presentation that should deal with multi site cloud, distributed etc.
15:09:25 <ad_rien_> anything else?
15:09:38 <ad_rien_> if not let's move to the next point
15:09:40 <serverascode> not from me right now
15:09:51 <ad_rien_> #topic deployment scenarios
15:10:24 <ad_rien_> Ok as mentioned in the pad, I think it would be valuable to spend sometimes on this point in order to move forward.
15:10:37 <dsantoro> we have analysed the proposed scenarios regarding our action item
15:10:47 <ad_rien_> maybe we can start from FBK institute
15:10:49 <ad_rien_> :)
15:10:53 <dsantoro> from the last meeting
15:10:58 <ad_rien_> please dsantoro
15:11:00 <dsantoro> yes thanks ad_rien_
15:11:11 <dsantoro> Description of our use casesDuring past months we started to analyze few use cases in which our platform could fit and the relative motivation to have a distributed IaaS layer, finally we identified few:
15:11:11 <dsantoro> Smart traffic light
15:11:11 <dsantoro> Here is important to overcome network faults and latency having a system more resilient
15:11:11 <dsantoro> Application placements and roaming (see demo paper @ CloudCom 2016)
15:11:11 <dsantoro> Here we need persistent storage on the edge to save application state and support the migration of the stateless components
15:11:11 <dsantoro> Virtual reality gaming
15:11:11 <dsantoro> Need to have the video elaboration and the application state on the edge due to low latency requirements
15:11:12 <dsantoro> Privacy and data
15:11:12 <dsantoro> Again need of storage on the edge
15:11:13 <dsantoro> Distributed content caching on the edge
15:11:13 <dsantoro> Probably need of placement control over the distributed storage
15:11:14 <dsantoro> Dimensioning and optimization of the control channel
15:11:51 <dsantoro> so about our preferred choice:
15:11:59 <dsantoro> Based on the above use-cases we would exclude s1 and s2 for the final platform mainly because we need availability of all resources offered by a IaaS in the edge not only computational resources. Maybe what we are looking for is a yet different scenario in which we have a complete (but small) OpenStack environment installed on the edge nodes that are federated with others.
15:12:49 <dsantoro> finally, since the WG agreed to start with testing s1 we think it could be a good architecture where to start also our experiments on bare metal edge nodes we would like to setup in the near future.
15:13:21 <ad_rien_> dsantoro:  are you done?
15:13:27 <dsantoro> yes
15:13:29 <ad_rien_> thanks
15:13:42 <ad_rien_> so regarding the first remark, I think you right,
15:13:54 <ad_rien_> HA can be an issue with S1
15:14:15 <ad_rien_> but this is the simplest way to operate a massively distributed cloud
15:14:41 <ad_rien_> the idea would be to evaluate the impact of network latency, bandwidth and disconnections
15:15:16 <ad_rien_> When you said: "because we need availability of all resources offered by a IaaS in the edge not only computational resources."
15:15:25 <dsantoro> sure and in some use-cases HA is vital like in traffic light example
15:15:27 <ad_rien_> what do you mean by not only computational resorces ?
15:15:37 <ad_rien_> resources sorry sir
15:16:01 <ad_rien_> i.e. we can maybe envision to run some workloads (either in VM or container sandboxing technologies)
15:16:10 <dsantoro> I mean that basically we think we need for sure CPU and RAM capacity on the edge node
15:16:26 <ad_rien_> at the edge and these workloads can be temporarily disconnected from the rest of the architecture.
15:16:45 <dsantoro> but for instance we are thinking on scenarios where we need to cache data (of videos) for example
15:16:48 <dsantoro> inthe edge nodes
15:16:50 <ad_rien_> (i.e. the important aspect is that those workloads can discuss with the edge sensors, facilities)
15:16:57 <ad_rien_> ok ?
15:17:00 <dsantoro> so in this case we ned soem sort of distributed storage also
15:17:04 <ad_rien_> ok
15:17:20 <ad_rien_> basically you are tallking abou having swift
15:17:29 <dsantoro> yes
15:17:30 <ad_rien_> (or a swift like solution)
15:17:33 <dsantoro> could be
15:17:44 <ad_rien_> swift is already distributed so this could be feasible but this is a good remark
15:18:01 <ad_rien_> try to extend this deployment scenarios analysis with the swift component
15:18:23 <ad_rien_> #action Extend the scenarios deployment with object stores servies such as Swift.
15:18:39 <dsantoro> we analysed also the case in which we have a stateless tier of an applicaiton
15:18:47 <dsantoro> running on the IoT GWs
15:19:01 <ad_rien_> can you elaborate a bit more?
15:19:01 <dsantoro> and it needs stateful/persitence on the edge node
15:19:08 <dsantoro> to support migration
15:19:25 <ad_rien_> not sure I correctly understood the point. Can you please explain?
15:19:30 <dsantoro> (this is what we shown during CloudCom)
15:19:45 <ad_rien_> ok
15:19:51 <ad_rien_> I remind the IoT gateway use-case
15:19:55 <dsantoro> image to have a container running on the closest layer in the GW (very close to user)
15:20:03 <ad_rien_> ok
15:20:23 <dsantoro> that container retrieve temperature data form a user sensor
15:20:29 <dsantoro> now the user move
15:20:30 <ad_rien_> so you have a container running on the Gateway, right? and what are the requirement on the edge cloud?
15:20:33 <ad_rien_> ok
15:20:41 <ad_rien_> go on please
15:20:44 <dsantoro> to GW2
15:20:49 <dsantoro> what we did
15:21:06 <dsantoro> was to distroy the container on GW1 and crete it on GW2
15:21:21 <ad_rien_> ok
15:21:22 <dsantoro> of course we need some persistent layer where to save the data collected form GW1
15:21:28 <ad_rien_> ok
15:21:39 <dsantoro> that layer in our demo was a DB
15:21:42 <dsantoro> on the edge
15:21:56 <ad_rien_> so the point is that you need to ensure that data can be shared at any time and under any constraints between the different edge clouds.
15:22:17 <dsantoro> yeah that's the point
15:22:38 <ad_rien_> (if obviously the two IoT gateways are attached to distinct edge clouds)
15:22:39 <dsantoro> microservices application could be distributed across GWs and EDGEs
15:22:49 <ad_rien_> Ok I get the point
15:23:06 <ad_rien_> so here it is a bit tricky in the sense that you are at the level of the data plane
15:23:06 <dsantoro> good
15:23:21 <dsantoro> let me tell you another quick point
15:23:34 <ad_rien_> and you want to ensure that your wokloads can communicate or at least adapt to external events such as network disconnections
15:23:40 <ad_rien_> am I right?
15:23:48 <dsantoro> yes you are right
15:24:17 <dsantoro> look this: in some cases we could need to store privacy information on the edge nodes
15:24:40 <dsantoro> imaging a health center that do not want to share users sensible infos on the cploud
15:24:52 <ad_rien_> ok I put some notes in the pad thanks, please go on
15:25:03 <dsantoro> so that the reason why we think is important having storage on the edge also
15:25:29 <ad_rien_> I agree
15:25:38 <ad_rien_> I added that line 152.
15:26:13 <ad_rien_> actually because swift is already based on a distributed model (i.e. a DHT-based blob system), we didn't put in the slides but you're right we should add it.
15:26:54 <ad_rien_> #action Identify impact not only at the level of the core-services but also at the level of the data plane.
15:27:00 <ad_rien_> ok anything else ?
15:27:12 <dsantoro> not from my side
15:27:19 <ad_rien_> ok thanks
15:27:24 <ad_rien_> precious comments ;)
15:27:52 <ad_rien_> so getting back to the slides. Joe(Chaoyi) added a few comments.
15:27:59 <ad_rien_> It would be great if we can all do the same
15:28:11 <ad_rien_> and try to criticize the different approaches
15:28:17 <ad_rien_> in term of performance, HA, ….
15:28:23 <ansmith> dsantoro: to clarify, is data collected from IoT gateway events/logs?
15:28:33 <ansmith> or other data?
15:28:52 <dsantoro> other data
15:29:12 <dsantoro> we had a GW with a datareader container onboard
15:29:27 <dsantoro> which collected temperature data from an attached sensor
15:30:18 <ad_rien_> dsantoro:  do you have a link toward you paper, it would be good to have it in the minutes (I think it might interest people)
15:31:18 <ad_rien_> ?
15:31:42 <dsantoro> sorry guys
15:32:04 <ad_rien_> #link http://ieeexplore.ieee.org/abstract/document/7830723/
15:32:09 <ad_rien_> but I didn't find the pdf :(
15:32:25 <ad_rien_> (at least a preprinted version that we can share)
15:32:33 <dsantoro> for sure I can share it by mail but I need to check this point of having it on a public link
15:32:53 <dsantoro> I will add it on the etherpad after cheking ok ?
15:32:59 <ad_rien_> guys if you are interested by additional information on the envisioned use-cases at FBK, please contact dsantoro by mail
15:33:04 <ad_rien_> or give a look to the pad ;)
15:33:09 <ad_rien_> Thanks dsantoro
15:33:17 <ad_rien_> ok so let's move forward,
15:33:59 <ad_rien_> so I didn't find time to polish the slide but as mentioned now I think we should add comments on the different approaches and clearly mention the pros/cons of each approach
15:34:25 <ad_rien_> I will do but from my perspective/my understanding. It would be great if you guys, you can add comments like Joe did
15:34:44 <ad_rien_> do you think you can give a try for the next meeting ?
15:35:18 <ad_rien_> Follks from Orange also made a good work on that aspect BTW
15:35:20 <jfpeltier> yes
15:36:17 * ad_rien_ is looking for another link
15:37:46 <ad_rien_> I think it should be that one
15:37:48 <ad_rien_> #link http://ieeexplore.ieee.org/abstract/document/7785190/
15:38:26 <jfpeltier> yes thanks
15:38:27 <ad_rien_> ok so action for the next meeting:
15:39:11 <ad_rien_> #action all: please add pros/cons comments on the deployment scenario  slides by Feb, the 13
15:39:35 <ad_rien_> #action adrien: polish the slide before the next meeting (i.e. between Feb the 13th and the 15th)
15:39:38 <ad_rien_> ok
15:39:45 <ad_rien_> anything else on this topic?
15:40:04 <ad_rien_> so let's switch to the next point
15:40:24 <ad_rien_> #topic Boston presentations
15:40:38 <ad_rien_> so first question, who plan to attend the Boston summit next May?
15:40:53 <ad_rien_> from Inria we should be two
15:41:03 <ad_rien_> who else?
15:41:17 <jfpeltier> not going
15:41:21 <ansmith> will attend
15:42:02 <serverascode> I'll be there :)
15:42:13 <ad_rien_> jfpeltier:  do you know whether mrohon or Abdelhdi will come?
15:42:30 <ad_rien_> ok
15:42:41 <dsantoro> none of us will attend probably
15:42:44 <ad_rien_> serverascode
15:42:47 <ad_rien_> dsantoro:  ok too
15:42:53 <kgiusti> kgiusti: planning to attend
15:43:20 <ad_rien_> ok
15:43:21 <ad_rien_> thanks
15:43:24 <jfpeltier> not sure yet for Abdelhadi, Mrohon maybe
15:43:56 <ad_rien_> so I put remarks regarding official presentations.
15:44:00 <ad_rien_> I have nothing to add
15:44:32 <ad_rien_> in particular, maybe just that I'm waiting for the serverascode proposal because I'm convinced that we are addressing similar challenges and that both WGs are valuable.
15:45:04 <ad_rien_> So does anyone plan to submit another presentation?
15:45:41 <dsantoro> no from our side mainly because the short deadline for submission we are not able to drive a proposal on our use-cases/platform
15:45:52 <dsantoro> but we are interested in contributing with few slides describing the use-cases, the platform or the requirements in the case you think is worth to mention about it on your Proposal 1.
15:46:01 <ad_rien_> ok
15:46:06 <ad_rien_> good to know that
15:46:31 <ad_rien_> #action keep FBK folks in the loop for the presentation in order to present their use-case in the introduction
15:46:55 <ad_rien_> ok maybe a last point to discuss is
15:47:45 <ad_rien_> What you would like to discuss during the massively distributed WG session (i.e. face to face meeting)? and whether it makes sense to provide a webconference solution for the ones that cannot make the trip to Boston.
15:47:57 <ad_rien_> I will open a pad so we can start to put items
15:48:26 <ad_rien_> #action Adrien create a pad for the face-to-face meeting in Boston (please double check that there is no overlapping with the NFV one)
15:48:53 <ad_rien_> serverascode: may I ask you how many session you plan to request for the NFV WG?
15:49:20 <serverascode> I did put in a request for two consecutive, but I would be surprised to get it
15:49:25 <ad_rien_> ok
15:49:29 <serverascode> I would imagine one 40 min session
15:49:31 <ad_rien_> good to know
15:49:46 <ad_rien_> ok if makes sense we can merge our session so we can have two consecutive sessions
15:50:08 <ad_rien_> let's see what will we get as preliminary agendas.
15:50:14 <serverascode> that's a possibllty, though we tend to get a lot of people who aren't necessarily interested :)
15:50:19 <serverascode> they just see NFV in the title
15:50:24 <ad_rien_> yes
15:50:27 <ad_rien_> like us ;)
15:50:31 <ad_rien_> they see Fog/Edge ;)
15:50:37 <ad_rien_> ok so let's move to the OpenDiscussion
15:50:47 <ad_rien_> #topic open discussions
15:51:24 <ad_rien_> jfpeltier:  I do not know whether you see the comments ansmith and kgiusti put in the pad: maybe you want to say a few words or we can keep this item for the next meeting?
15:52:10 <ad_rien_> (I would  like to keep 3 minutes at least to discuss the  last point: how can we attract more people).
15:52:14 <jfpeltier> yes we can keep that for next one as we don't have clear cut results yet
15:52:45 <kgiusti> fyi: andy and I have thrown together some slides on different message bus deployment topologies: https://docs.google.com/presentation/d/1ghwinrArfoCw1qIsNGxWSrd8NTynYomThERGUpN4f0U/edit?usp=sharing
15:52:51 <ad_rien_> ok #action jfpeltier (Orange) will provide information regarding the AMQP stresser)
15:53:06 <ad_rien_> #link https://docs.google.com/presentation/d/1ghwinrArfoCw1qIsNGxWSrd8NTynYomThERGUpN4f0U/edit?usp=sharing
15:53:16 <jfpeltier> basically the AMQP flooding is issued by sending many messages to the clients on one-to-one queues
15:53:17 <kgiusti> we can talk about this next meeting once folks have time to look it over.
15:53:28 <jfpeltier> ok
15:53:45 <ad_rien_> kgiusti:  ACL
15:53:46 <ad_rien_> ACK
15:53:50 <ad_rien_> I put it on the pad thanks
15:53:54 <ad_rien_> will definitely give a look
15:54:07 <ad_rien_> BTW guys, do you think we can find a way to deploy QPID with ansible ?
15:54:37 <ad_rien_> or any glue that can enable us to deploy it easily/in an automatic manner.
15:54:40 <kgiusti> jfpeltier: stressing the broker itself - would be interesting to see how the other more point to point (non-brokered) technologies handle that (zeromq, dispatch router)
15:54:59 <ansmith> ansible is next up after we complete tripleo/puppet
15:55:14 <ad_rien_> May I ask you a milestone/deadline?
15:55:20 <ad_rien_> even if it is approximatie
15:55:29 <ad_rien_> s/approximatie/approximative.
15:55:46 <ansmith> during pike is goal, in meantime we can discuss manual configuration if that is an option
15:55:58 <ad_rien_> we can try it
15:56:08 <ad_rien_> but manual means having a permanent testbed
15:56:20 <ad_rien_> we have a permanenent testbed but with more than 1000 users
15:56:28 <ad_rien_> so we get leases/reservations
15:56:37 <ad_rien_> it is preferable to have an automation mode.
15:56:41 <ad_rien_> Ok we can discuss that point later
15:56:47 <ad_rien_> last question:
15:56:50 <ansmith> understood, will provide update
15:57:02 <ad_rien_> did you get feedbacks from RED Hat Fog/Edge guys?
15:57:21 <ad_rien_> It would be great to have them in our discussions: ansmith?
15:57:26 <ad_rien_> any news on that point.
15:57:28 <ad_rien_> ?
15:57:33 <ansmith> we reached out to a number of folks who are interested in the wg
15:57:46 <ansmith> I will invite them to next session
15:57:50 <ad_rien_> ok sounds good
15:58:05 <ad_rien_> especially that now we have FBK that is strongly supporting Fog/Edge use-cases
15:58:25 <ad_rien_> #info Fog/edge folks from redhat should join us next time
15:58:30 <ad_rien_> Ok nothing more from my side
15:58:34 <ad_rien_> Thanks for attending the meeting
15:58:46 <ad_rien_> we have one more minute if someone wants to add something?
15:58:55 <ad_rien_> nothing ?
15:58:58 <serverascode> nothing from me
15:59:07 <ad_rien_> Ok thanks.
15:59:10 <ad_rien_> #endmeeting