15:00:09 <Menthos> #startmeeting massively_distributed_clouds
15:00:13 <openstack> Meeting started Wed Dec  7 15:00:09 2016 UTC and is due to finish in 60 minutes.  The chair is Menthos. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:17 <openstack> The meeting name has been set to 'massively_distributed_clouds'
15:00:27 <Menthos> Hi guys.
15:00:56 <rcherrueau> o/
15:00:58 <HeleneCoullon> Hi
15:00:59 <denaitre> hi
15:01:02 <ansmith> o/
15:01:10 <mabderrahim> o/
15:01:19 <kgiusti> o/
15:01:27 <Menthos> I am chairing this session as our beloved ad_rien is travelling today
15:02:03 <Menthos> May I ask who's online?
15:02:15 <Menthos> Should we wait one more minute?
15:03:38 <Menthos> Can you please add your names to the pad? Line 80
15:03:41 <Menthos> #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2016
15:04:40 <Menthos> Ok so I guess we can start :-)
15:04:48 <Menthos> #topic Glossary: define missing key terms
15:05:24 <Menthos> If you look at the pad, line 94, you will see a list of missing terms from the glossary
15:05:45 <Menthos> From the terms we defined last week, only region is already in the glossary
15:06:41 <Menthos> It would be interesting if everyone tried to add their own definitions to the pad (lines 95-99) so we can  agree on definitions that suit everybody
15:09:02 <Menthos> ansmith: what do you do think of these definition at redhat? (e.g. site)
15:10:01 <ansmith> will take action to look for definitions if they exist here at rh
15:10:33 <Menthos> #action ansmith look for definitions at redhat
15:10:42 <Menthos> thanks ansmith
15:11:23 <Menthos> mabderrahim: what about Orange? I feel like a telco vision would be different from redhat for example
15:12:29 <Menthos> Ok I think we can leave this for now and advance on the definitions offline
15:12:37 <mabderrahim> I am trying to formulate a definition of the backbone
15:12:47 <Menthos> mabderrahim: thanks :-)
15:12:58 <mabderrahim> welcom :)
15:13:58 <Menthos> So maybe we can move on to the next topic
15:14:36 <Menthos> And hopefully by the next meeting we will have this glossary all filled up with our massively distributed verbiage
15:14:48 <Menthos> #topic Define deployment scenarios
15:15:10 <Menthos> So ad_rien created the following document
15:15:12 <Menthos> #link https://docs.google.com/presentation/d/1jJFZejZqgYDxu5FX4K8g3I5zQ87afnjYI4VSRSuCQ6U/edit?usp=sharing
15:15:27 <ansmith> very nice doc
15:15:37 <Menthos> The idea is to describe the possible scenarios for massively distributed clouds
15:16:04 <Menthos> Maybe we will not agree on everything, so please put your own :-)
15:16:22 <Menthos> Then there is the special case of cells…
15:17:06 <Menthos> Well, the first deployment is when everything is centralized but the compute nodes.
15:17:25 <Menthos> The control nodes and the compute nodes are connected with a WAN
15:17:53 <Menthos> Then we are having trouble defining what is a typical cell deployment
15:19:06 <Menthos> ansmith: thanks for you question about abstracting rabbitmq. Actually we have the same question
15:19:48 <Menthos> And I think you are right, we should probably replace rabbitmq with AMQP in the diagram
15:20:10 <ansmith> I would not suggest replacing with AMQP but rather oslo.messaging
15:20:23 <Menthos> Okay :-)
15:20:45 <ansmith> then as we distinguish RPC from notification interactions we can then analyze across the backend types
15:21:01 <ansmith> kgiusti: do you agree?
15:21:19 <kgiusti> ansmith: yes
15:21:35 <Menthos> ansmith: can you ellaborate?
15:21:36 <ansmith> and does it make sense to show that oslo.messaging is present at all the sites?
15:22:19 <Menthos> Oh I see
15:22:41 <Menthos> We only considered the server, but not the agents
15:22:46 <ansmith> yes
15:22:46 <Menthos> We should add them
15:23:43 <ansmith> as the openstack services get deployed across the different scenarios, there may be implications on the messaging patterns
15:24:41 <msimonin> Hi guys !
15:25:39 <Menthos> kgiusti: would Qpid change this picture?
15:26:20 <kgiusti> I don't think so - not at this level of detail.
15:26:26 <kgiusti> ansmith: do you agree?
15:26:47 <ansmith> agree, doesnt change things at the scenario level but when we go to the next level down
15:27:00 <Menthos> Good
15:27:05 <ansmith> the differences of broker-backed, brokerless models will show up
15:27:05 <Menthos> What about cells?
15:27:12 <Menthos> (slide 3)
15:27:13 <ansmith> e.g. latency, bandwidth, etc.
15:27:55 <kgiusti> ansmith: right - with 'oslo.messaging' we have several messaging backend deployment options: brokered, zmq, routed, even kafka
15:29:24 <Menthos> kgiusti: agreed
15:30:31 <rcherrueau> I have a question on slide 2: If I understand correctly, in the site 0 the AMQP box represents the AMQP bus server. The idea then is that you used oslo.messaging to deliver and get messages on this bus. So my question is, does this architecture is still correct if you go with qpid
15:31:39 <kgiusti> rcherrueau: just to be specific: there is a qpidd broker and there is a qpid router.  In the qpidd case, the arch would be the same.
15:32:11 <kgiusti> rcherrueau: in the routed case we would need both a broker (for notifications) and routers for the RPC traffic
15:32:27 <rcherrueau> kgiusti: ok thank you for the clarification
15:32:32 <ansmith> sugest that AMQP be depicted as oslo.mesaging on slide 2, site 0
15:32:39 <ansmith> as that is the "service" in the scenario
15:32:54 <kgiusti> rcherrueau: in that case a single broker on site 0 would probably be the case, but for rpc we'd want a router co-located at each site
15:34:03 <Menthos> Alright
15:34:12 <kgiusti> in general - at this level are we making a specific choice regarding the actual messaging bus used (rabbitmq, qpidd, router)?  I don't think we're there yet.
15:34:51 <Menthos> kgiusti: I agree − we should have the most amqp-agnostic design as possible at this point
15:35:02 <Menthos> Can we have a look at slide 3?
15:35:04 <kgiusti> so using 'oslo.messaging' at each site allows a 'placeholder' for each type of messaging system we want to evaluate
15:35:12 <kgiusti> Menthos: +1
15:35:16 <Menthos> And cells :-)
15:35:24 <Menthos> This one is really hard IMO
15:35:47 <msimonin> kgiusti: agreed about oslo.messaging
15:36:36 <Menthos> We tried to come up with a design, but we tend to think that cells, as a nova feature, do precisely define what happens to the other services
15:36:45 <Menthos> do not*
15:37:22 <Menthos> So the question is: where would we put glance? And neutron server?
15:37:29 <Menthos> Are they shared?
15:37:40 <Menthos> Or is there one per cell?
15:38:31 <Menthos> No cell power users here?
15:40:02 <Menthos> Or any remark on the other scenarios?
15:41:59 <Menthos> Between slides 4 and 5, the difference is where we should put glance
15:42:28 <Menthos> Either centralized at the top site, or distributed in every site
15:42:38 <Menthos> Any opinion on that?
15:42:39 <msimonin> I would say they are both possible
15:42:42 <msimonin> :)
15:43:06 <Menthos> But what would be the impact/the best for a particular use-case?
15:44:02 <Menthos> mabderrahim: I'm sure Orange as an opininon on that, at least from the network perspective
15:44:15 <Menthos> But time is running out, so I'll put an action
15:44:24 <Menthos> And we can discuss it next time
15:45:12 <Menthos> #action Define the design (slide) for a cell-based scenario, and describe the impact of the placement of glance
15:45:26 <Menthos> #topic Expected capabilities and features for massively distributed clouds
15:46:06 <Menthos> So what features/capability should be expect at the site/region level?
15:46:21 <Menthos> (Imagine we have defined site and region :-))
15:48:04 <Menthos> For example on VM migration: is this something you would expect? In this case the network functionalities will need to adapt
15:49:03 <msimonin> Maybe we can start by asking
15:49:10 <msimonin> Why do we need VM migrations ?
15:49:57 <Menthos> Balancing the load between sites, maintainance…
15:50:25 <Menthos> Actually it probably depends on 1) the size of the sites and 2) the mobile-edge use-case
15:50:45 <Menthos> Again, I am summoning our telco friends :-)
15:50:54 <msimonin> :)
15:50:59 <Menthos> mabderrahim: ?
15:51:26 <mabderrahim> I that we can consider the performances offered by each site as a positve factor
15:51:46 <mabderrahim> and the transmission time between the site as a negative factor
15:52:18 <mabderrahim> To evaluate the transmission time accurately
15:52:38 <mabderrahim> we may include the bandwith and the latency of the link
15:53:07 <mabderrahim> There is also the distance between the sites that we may consider
15:53:30 <Menthos> Okay
15:53:42 <Menthos> Maybe it's time to move to open discussion?
15:53:49 <Menthos> #topic Open discussion
15:54:34 <Menthos> Is there something you would like to address in less than 6 minutes?
15:54:55 <msimonin> mabderrahim: are you giving criterias to take into account while making the decision to migrate ?
15:56:14 <Menthos> Has anyone looked at the kingbird project?
15:56:17 <Menthos> #link https://github.com/openstack/kingbird/
15:56:33 <msimonin> what is it ? :)
15:56:55 <Menthos> Centralized management for distributed deployment
15:57:26 <Menthos> From what I understand, a answer to questions like "how many instances do I have" in the context of muli-regions
15:57:38 <Menthos> (Still a hard question in cells v2, I think)
15:57:49 <msimonin> hum I see
15:57:54 <ansmith> Kingbird is a part of the OPNVF Multisite project
15:58:18 <ansmith> there are a number of OPNVF projects that may relate to discussions here
15:58:31 <Menthos> seems like it
15:58:42 <mabderrahim> I think before migrating the service we should calcuate the time of the interruption of the service, the load in the hostinig site
15:58:48 <msimonin> sure
15:58:52 <msimonin> mabderrahim: ack
15:58:54 <mabderrahim> the congestion of the network
15:59:11 <mabderrahim> betwenn both sites
15:59:12 <Menthos> I am sorry but it will be time to close very soon :-)
15:59:19 <msimonin> We should discuss use cases where migration are mandatory
15:59:22 <Menthos> #endmeeting