15:00:15 <Menthos2> #startmeeting massively_distributed_clouds
15:00:15 <openstack> Meeting started Wed Mar 15 15:00:15 2017 UTC and is due to finish in 60 minutes.  The chair is Menthos2. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:19 <openstack> The meeting name has been set to 'massively_distributed_clouds'
15:00:33 <Menthos2> #chair ad_rien_
15:00:34 <openstack> Current chairs: Menthos2 ad_rien_
15:00:37 <Menthos2> Hi there
15:00:59 <Menthos2> ping ad_rien_, msimonin, denaitre, dsantoro, menthos,  serverascode, jfpeltier, kgiusti, ansmith
15:01:20 <dsantoro> Hello
15:01:30 <ad_rien_> Hi o/
15:01:32 <Menthos2> ping rcherrueau
15:01:32 <denaitre> hey o/
15:01:36 <msimonin> o/
15:01:40 <ansmith> o/
15:01:43 <Menthos2> So who's with us today?
15:01:43 <rcherrueau> :)
15:01:43 <msimonin> rcherrueau:  ping
15:01:44 <mabderrahim> hi o/
15:01:52 <rarora> hi
15:01:52 <kgiusti> o/
15:01:57 <paul-andreraymon> hi
15:02:19 <Menthos2> Hi everyone
15:02:25 <Menthos2> Let's just take one more minute
15:03:06 <Menthos2> Okay let's start
15:03:21 <Menthos2> #topic Announcements
15:03:38 <Menthos2> So good news from our side, we have two presentations accepted at the Boston summit
15:03:45 <Menthos2> And one forum
15:03:54 <jamemcc> Hi
15:03:56 <Menthos2> (but the forum planning is still under discussion)
15:04:27 <ad_rien_> Folks, please if you plan to attend the summit add your name in the last section of our minutes
15:04:34 <Menthos> Anyone wants to share some news from their side?
15:06:35 <ad_rien_> mabderrahim:  do you know whether jf peltier or Mat Rohon will join us ?
15:06:41 <jamemcc> From the LCOO side - pretty distantly related probably but would like to get any help from those here who have put some thought into similar.  LCOO and more myself have submitted a User Story to the Product Workign Group process to get started with an analysis for Cloud Native principles
15:07:00 <mabderrahim> no in fact I haven't any idea
15:07:15 <jamemcc> #URL https://review.openstack.org/#/c/444611/
15:07:58 <ad_rien_> #link https://review.openstack.org/#/c/444611/ cloud native stories
15:08:15 <Menthos> jamemcc: can you tell us more?
15:08:32 <ad_rien_> what is the meaning of cloud native principles :-)
15:08:32 <ad_rien_> ?
15:09:09 <paul-andreraymon> Are there specific principles for Cloud Native in a Massively distributed environment?
15:09:11 <jamemcc> The idea of cloud native in generaal is to break down your application so it can more efficiently run as a stateless and small but easy to scale and distribute way
15:09:29 <ad_rien_> ok
15:09:32 <Menthos> Oh I see
15:09:45 <msimonin> is Openstack cloud native ?
15:09:55 <Menthos> So your question is do we have specifics requirements for doing that on massively distributed clouds?
15:10:06 <jamemcc> As various teams - most notably Kolla and now OpenStack-Helm which is trying to bring Kubernetes OpenSource world together with OpenStack
15:10:29 <jamemcc> are making progress it seems we need some underlying guidlies to help us sort it out
15:10:49 <ad_rien_> sorry not sure I correctly understood the question:
15:10:56 <ad_rien_> Is it related to the deployment of OpenSTack itself ?
15:10:57 <jamemcc> Most notably for the OpenStck itself - in LCOO we differentiate this as being Containerized COntrol Plane
15:11:01 <jamemcc> Yes
15:11:04 <ad_rien_> ok
15:11:15 <ad_rien_> So we have started a study here @inria
15:11:37 <ad_rien_> for the moment we identified all tools available in the openstack ecosystem
15:11:54 <ad_rien_> define a first workflow (based on kolla)
15:12:02 <ad_rien_> a technical repport should be available soon
15:12:28 <ad_rien_> The idea is to define how you can deploy (and then upgrade) a distributed version of OpenStack
15:13:00 <jamemcc> @msimonin - I'm far from the expert but as I understand - projcts are using many good contructs of Cloud Native - most notably REstFul interfaces - but no - in general architected as a larger/even single architecture
15:13:19 <ad_rien_> jamemcc:  paul-andreraymon: does it correpsond to your idea ?
15:14:39 <Menthos> To add to what ad_rien_ just said, @Inria they worked more on how to deploy applications on massively distributed clouds
15:14:48 <Menthos> Not really about applications life cycle
15:14:48 <paul-andreraymon> It does.  But Intuitively, I would think there is a little more.
15:14:54 <msimonin> jamemcc: ok, is there some references of those constructs of a Cloud Native app ?
15:15:24 <paul-andreraymon> If I create a microservice, there are specific things to be done to make it cloud native.
15:15:36 <jamemcc> Defiantely an overlap - we were thinking it is just more about reanalyzing each of the projects to see if they could be and should be redesigned to better enable Cloud Native priciples, but defiantely distributing the computing and also more efficiently supporting maintenance are key outcomes.
15:16:14 <Menthos> And we welcome HeleneCoullon who works on this @Inria :-)
15:16:28 <jamemcc> In fact he suer story is more about specifiying those goals then it is in doing an exhaustive list of the types of ways to redesign
15:16:38 <ad_rien_> Maybe the first question from the massively distributed WG perspective is to identify an application that needs to be deployed at WAN scale (i.e between multiple sites)
15:16:52 <msimonin> jamemcc:  Actually, I may be wrong, but some study @inria are about edge or fog native applications
15:17:09 <HeleneCoullon> o/
15:17:13 <Menthos> ad_rien_:  …and then what do we need to do to this application to make it run on an edge cloud
15:17:28 <Menthos> Maybe we should add this to the agenda for the next meeting?
15:17:33 <dsantoro> @msimonin: a reference is for sure the 12th factor —> https://12factor.net/
15:17:34 <ad_rien_> +1
15:17:52 <Menthos> thanks dsantoro
15:18:16 <msimonin> dsantoro: I see :)
15:18:17 <ad_rien_> Cloud Native Principles/Microservice approach for OpenStack - Implementing techniques to all of the projects so that they can be instantiated in a MicroService type fashion.  This leads to scalability and operational flexibility in large clouds. ?
15:18:31 <ad_rien_> Is it related to that point I copied/pasted to the boston summit etherpad:
15:18:42 <ad_rien_> #link https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge Boston pad
15:18:51 <ad_rien_> if yes. I propose to discuss that point later
15:19:06 <ad_rien_> (espeecially because It appears at the end of the agenda)
15:19:10 <Menthos> #action all Discuss Cloud Native app principles for Massively Distributed Clouds
15:19:39 <Menthos> Can we move on?
15:20:01 <Menthos> #topic AMQP
15:20:25 <ad_rien_> We have two points to be discussed:
15:20:34 <ad_rien_> the slides from kgiusti
15:20:49 <ad_rien_> and additional informations regarding the AMQP stresser from Orange
15:21:22 <ad_rien_> so unfortunately from our side, we did not spend enough time
15:21:36 <ad_rien_> so I know msimonin gave a look at
15:21:52 <ad_rien_> but he cannot attend this meeting too
15:22:13 <rcherrueau> I have a question for ansmith and kgiusti about their slides. What kind of messages goes through notification traffic? Is it stuff like compute heart-beat or is it something that required a pub/sub model?
15:23:19 <kgiusti> rcherrueau: notifications are typically used for telemetry, logging and billing, etc
15:23:50 <kgiusti> rcherrueau: heartbeats - not likely, but I would need to check the impl to be sure
15:24:14 <kgiusti> rcherrueau: usually that's a 'cast' RPC operation (RPC without returning a value)
15:24:44 <kgiusti> rcherrueau: but again I'll have to confirm that in the code.
15:25:00 <rcherrueau> I would say that telemetry will use the REST API no?
15:25:30 <Menthos> kgiusti: so you mean ATM there is no optimisation and it is all RPC calls?
15:25:47 <kgiusti> rcherrueau: perhaps - again I need to check the code.
15:26:15 <kgiusti> Menthos: the applications are free to implement whatever traffic pattern they see fit.
15:26:37 <kgiusti> Menthos: quite possibly using Notifications for heartbeat
15:26:44 <Menthos> applications or OpenStack services?
15:26:52 <kgiusti> Menthos: Openstack services
15:27:41 <kgiusti> Menthos: Notifications re: billing could be stored to disk (durable) to prevent loss.
15:27:57 <Menthos> So the reason for this notification service is one-to-one vs one-to-many?
15:28:03 <Menthos> Notifications are one-to-many?
15:28:13 <kgiusti> Menthos: one to many, yes
15:28:35 <kgiusti> Menthos: but not truly pub/sub -
15:28:43 <Menthos> So why not using something like a distributed pub-sub system instead of a centralized broker?
15:28:48 <Menthos> Oh
15:28:55 <Menthos> I see
15:29:24 <rcherrueau> and what about probabilistic broadcast to implement such one-to-many link without a broker (ie, in a fully decentralized manner)
15:29:25 <kgiusti> Menthos: under the current impl the notification messages are competed for by all subscribers.
15:29:55 <kgiusti> Menthos: so the actual functionality is like a shared queue - go figure it was a surprise to me.
15:30:06 <Menthos> So it's a broadcast?
15:30:47 <kgiusti> Menthos: no - each notification is consumed by only one subscriber even if there are many subscribers
15:30:51 <kgiusti> Menthos: like a queue
15:31:07 <kgiusti> Menthos: but the Notification API is very high level - like a logging API
15:31:39 <kgiusti> Menthos: It is presumed that order is preserved (but not across multiple consumers) - like logging
15:31:47 <clauden> kgiusti: is there an exactly-once semantic?  or at-most?
15:31:57 <Menthos> So if it's one-to-one, why not using RPC calls?
15:32:11 <kgiusti> clauden: at-most
15:32:42 <kgiusti> Menthos: it's the API for Notifications that makes the difference really
15:33:02 <ad_rien_> ok
15:33:13 <kgiusti> Menthos: services that need to log events have a high-level logging like api (severity, filtering etc)
15:33:17 <ad_rien_> how can we try to identify concrete actions?
15:33:38 <ad_rien_> to be honest, I'm starting to be completely lost :(
15:33:44 <kgiusti> Menthos: you'd have to build your own on top of RPC if you wanted to use RPC
15:33:51 <kgiusti> ad_rien_: welcome to my nightmare
15:33:54 <ad_rien_> We should probably go deeper an try to clarify the ecosystem
15:33:57 <ad_rien_> kgiusti:  :)
15:34:03 <Menthos> Maybe we could add an action for next time?
15:34:07 <ad_rien_> There is also kafka
15:34:11 <Menthos> This is an interesting topic
15:34:18 <ad_rien_> in the big picture in the openstack ecosystem
15:34:36 <kgiusti> ad_rien_: oslo.messaging only support Notifications for kafka, not RPC
15:34:44 <kgiusti> ad_rien_: just fyi.
15:34:59 <ad_rien_> but we were talking about notifications ;-
15:35:00 <ad_rien_> )
15:35:02 <ad_rien_> just now
15:35:05 <clauden> seems like a core platform function to support a bunch of different scenarios...
15:35:10 <ad_rien_> yes
15:35:13 <kgiusti> ad_rien_: so kafka can be used as an alternative to "broker" in all those slides
15:35:19 <clauden> notifications can set up rdv for future RPC calls too :-)
15:35:24 <ad_rien_> that is my question :(
15:35:31 <ad_rien_> indeed
15:36:05 <paul-andreraymon> In Barcelona, there were also a lot of talks about ZeroMQ and its benefits. I believe oslo supports it.
15:36:21 <ad_rien_> ok so let's try to summarize the situation:
15:36:30 <ad_rien_> right now there is RabbitMQ.
15:36:33 <kgiusti> paul-andreraymon: +1 - see the slides it covers that
15:36:47 <ad_rien_> we all agree it is an issue
15:37:06 <ad_rien_> (i.e. RabbitMQ will definitely be able to tackle with our challenges)
15:37:11 <ad_rien_> Then we have zeroMQ
15:37:13 <ad_rien_> QPid
15:37:20 <ad_rien_> (and maybe Kafka)
15:37:33 <ad_rien_> so who can try to clarify this picture ?
15:37:47 <ad_rien_> Pros/Cons of the different approaches (conceptually and technically speaking)
15:38:06 <ad_rien_> ?
15:38:39 <kgiusti> ad_rien_: I attempted to do that in the slides: https://docs.google.com/presentation/d/1ghwinrArfoCw1qIsNGxWSrd8NTynYomThERGUpN4f0U/edit#slide=id.g1b279a0990_0_7
15:38:49 <ad_rien_> For ZeroMQ we discussed last time that the number of connexions to be maintained can be critical
15:39:08 <ad_rien_> yes kgiusti
15:39:14 <ad_rien_> thanks for that
15:39:22 <ad_rien_> it would be great to go deeper
15:39:46 <ad_rien_> how can we move forward?
15:39:53 <ad_rien_> We need to challenge kgiusti ?
15:40:09 <kgiusti> :)
15:40:20 <ad_rien_> (kindly challenge him ;))
15:40:34 <jamemcc> with utmost respet
15:40:35 <ad_rien_> the idea is to try to identify elements that cannot be debated anymore
15:40:56 <ad_rien_> something like: if you use zeroMQ you will face that and that issues
15:41:09 <ad_rien_> Kafka does not answer this point
15:41:18 <ad_rien_> and QPid will solve this but you have to accept that....
15:41:27 <ad_rien_> So maybe we can try to exchange by mail?
15:41:46 <ad_rien_> my proposal is: please if you are interested by taking part to this action
15:41:49 <ad_rien_> Add you email
15:42:08 <ad_rien_> so kgiusti rcherrueau can start a thread and we can move forward
15:42:18 <ad_rien_> what do you think.
15:42:19 <ad_rien_> ?
15:42:19 <clauden> is the topic of (broadly speaking) "coordinating activities across widely distributed OpenStack services" being worked anywhere else in parallel?
15:42:28 <kgiusti> ad_rien_: sure thing
15:42:44 <rcherrueau> ad_rien_: kgiusti yes good idea
15:43:08 <kgiusti> ad_rien_: I can start something on openstack-dev, have the other oslo folks weigh in
15:43:25 <ad_rien_> if you want but generally it is better
15:43:45 <ad_rien_> to start with a few folks get a first initial draft (as much complete as possible)
15:43:52 <ad_rien_> and then go on on the general ML
15:44:02 <ad_rien_> Otherwise you may receive a lot of noise
15:44:11 <ad_rien_> so it is up to you guys.
15:44:22 <ad_rien_> ok
15:44:30 <Menthos> 15 minutes lef, we should move on to the next topic
15:44:37 <kgiusti> ad_rien_: ok
15:44:39 <ad_rien_> so if we agree I propose to move to the next topic
15:44:42 <ad_rien_> great
15:44:59 <ad_rien_> so Folks from Orange: are you there?
15:45:20 <ad_rien_> seems not
15:45:22 <mabderrahim> me I am here
15:45:28 <jamemcc> FYI - claudn and I are here largely to field any questions about eCOMP
15:45:59 <ad_rien_> ok so seems not (thanks mabderrahim but I'm looking from Jf or Matt)
15:46:07 <mabderrahim> ok
15:46:29 <ad_rien_> BTW mabderrahim may make sense to take part to the discussion as you are rather familiar with kafka
15:46:33 <rcherrueau> kgiusti: could you, please. explicitly link me and paul-andreraymon in your mail on to the openstack-dev?
15:46:39 <ad_rien_> ok so let's move to the next topic
15:46:45 <Menthos> #topic ECOMP
15:47:04 <kgiusti> rcherrueau: will do
15:47:12 <rcherrueau> kgiusti: thanks
15:47:28 <ad_rien_> ok so first question:
15:48:01 <Menthos> #link http://lists.openstack.org/pipermail/user-committee/2017-February/001722.html
15:48:24 <ad_rien_> whether is it possible to arrange a short presentation by webconf?
15:48:40 <ad_rien_> I think we are several interested by understanding a bit more.
15:48:53 <Menthos> +1
15:49:01 <Menthos> But the timing is short
15:49:10 <paul-andreraymon> +1
15:49:17 <clauden> i think that an ecomp overview would be good, can't set it up in 9 minutes though :(
15:49:20 <ad_rien_> so jamemcc clauden would it be possible to arrange such a presentation
15:49:25 <ad_rien_> yes
15:49:32 <jamemcc> Yeah I think so - I'll take it offline with claude
15:49:33 <ad_rien_> so we can arrange a slot.
15:49:38 <ad_rien_> great
15:49:50 <jamemcc> Maybe same time but next week?
15:49:50 <ad_rien_> so can we do the same so we can open a doodle
15:49:59 <jamemcc> OK
15:50:05 <paul-andreraymon> Should the presentation be about AT&T's eCOMP or should it be about the new opensource ONAP of LinuxFoundation?
15:50:12 <ad_rien_> Follks that are interested by taking part in the ECOMP webconf presentation add your email
15:50:48 <jamemcc> #action jamemcc open doodle to get times setup for web/video conference intro to eCOMP
15:51:23 <clauden> there's a subset of "internal production" ECOMP in ONAP, we can talk about that as well as discussing the extensions/customizations that would go along with it... does that help?
15:51:59 <paul-andreraymon> clauden: Yes, I think it would help
15:52:25 <ad_rien_> Maybe we can have a rather large overview of ECOMP and then have some backup slides according to the questions/Discussions
15:52:33 <ad_rien_> jamemcc:  can you please take care about that ?
15:52:43 <ad_rien_> (sorry 8 min left)
15:53:09 <ad_rien_> we should move to the next point because I really want to highlight the question
15:53:11 <Menthos> #topip Enos
15:53:17 <Menthos> #topic Enos
15:53:19 <Menthos> :-)
15:53:34 <Menthos> I think we can cover this next time
15:53:47 <ad_rien_> I propose that we move this point to the next meeting (nothing special to mention but things are progressing)
15:53:51 <Menthos> #topic Open discussion
15:53:56 <ad_rien_> OK
15:54:03 <ad_rien_> so here is the important point.
15:54:16 <ad_rien_> In order to prepare the forum sessions in Boston, we should gather inputs
15:54:25 <ad_rien_> You can see the general one at
15:54:44 <ad_rien_> #link https://etherpad.openstack.org/p/BOS-UC-brainstorming general boston forum pad
15:55:09 <ad_rien_> and the one which is related to our WG
15:55:11 <Menthos> #link https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge
15:55:23 <Menthos> #undo
15:55:23 <ad_rien_> so may I ask all of you to add inputs
15:55:33 <Menthos> #link https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge massively distributed clouds forum pad
15:55:34 <ad_rien_> especially in the second one.
15:56:04 <ad_rien_> We will discuss it deeper next time but we should raise the major points we would like to discuss by the end of the week (deadline)
15:56:10 <jamemcc> Wanted to get this in the meetign minutes this is the Doodle link for finding the right time and participants for EComp intro
15:56:14 <jamemcc> #url http://doodle.com/poll/3by7n2mcxhg2aapk
15:57:16 <ad_rien_> for instance kgiusti ansmith may I ask you to add a section to discuss AMQP related questions ?
15:57:28 <ad_rien_> (3 min left)
15:57:30 <Menthos> #link http://doodle.com/poll/3by7n2mcxhg2aapk
15:57:42 <kgiusti> ad_rien_: sure
15:58:00 <Menthos> Anything more to add to the discussion?
15:58:08 <Menthos> (In less than 2 minutes)
15:58:26 <paul-andreraymon> jamescc: what time zone are you using for the doodle?
15:58:27 <ad_rien_> so two important points of today:
15:58:41 <ad_rien_> - please add your email in the pad if you are interested by
15:58:46 <ad_rien_> the AMQP discussions
15:58:54 <jamemcc> Should come up in your time but I am using US Central time
15:59:03 <ad_rien_> - please add your email in the pad (in the correct section ) if you are interested by the ECOMP presentation
15:59:04 <ad_rien_> Thanks
15:59:07 <ad_rien_> that's all from my side
15:59:12 <Menthos> So thank you all for coming today
15:59:23 <ad_rien_> (unfortunately discussions were fruitful today but we do not have anymore time)
15:59:25 <ad_rien_> Bye
15:59:26 <Menthos> #endmeeting
15:59:29 <rcherrueau> thanks
15:59:45 <ad_rien_> #endmeeting