#openstack-meeting log

15:00:12 <ad_rien_> #startmeeting massively_distributed_clouds
15:00:12 <openstack> Meeting started Wed Nov 23 15:00:12 2016 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:12 <ad_rien_> #chair ad_rien_
15:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:15 <openstack> The meeting name has been set to 'massively_distributed_clouds'
15:00:16 <openstack> Current chairs: ad_rien_
15:00:24 <ad_rien_> Hi guys.
15:00:34 <ad_rien_> May I ask you who is online ?(
15:00:38 <kgiusti> o/
15:00:45 <rcherrueau> o/
15:00:50 <foliveira> o/
15:00:51 <ad_rien_> Hi kgiusti
15:00:52 <ansmith> o/
15:01:14 <kgiusti> hello!
15:01:20 <mabderrahim> o/
15:01:32 <ad_rien_> so let's wait one or two minutes, meanwhile you can give a look to the agenda (line 21 of the pad)
15:01:38 <ad_rien_> #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2016
15:02:10 <ad_rien_> may I ask you to complete it (starting by who is attending the meeting today)
15:03:12 <denaitre> o/
15:03:14 <ad_rien_> ok so let's start
15:03:51 <ad_rien_> #topic barcelona sumup
15:04:18 <ad_rien_> as a reminder, the minutes we took during our face to face meeting in Barcelona are available at
15:04:26 <ad_rien_> #link https://etherpad.openstack.org/p/massively_distribute-barcelona_working_sessions
15:04:56 <ad_rien_> we identify a few actions that can be addressed during this cycle
15:05:12 <ad_rien_> - Identify deployment scenarios for massively distributed/fog/edge clouds (multi regions / one region with cells / one region with compute nodes deployed at the edge, ....)
15:05:12 <ad_rien_> - Identify technical challenges/limitations for each scenario (quotas, heat, network issues, live migration, ...)
15:05:12 <ad_rien_> - Identify evaluation scenarios (from the performance and functionnal viewpoint).
15:05:46 <ad_rien_> do you think we should add other action candidates in this list?
15:06:36 <ad_rien_> ok it seems to be ok.
15:07:31 <ad_rien_> foliveira:  ?
15:08:19 <ad_rien_> ok so the next question is then to put some priorities on each action
15:08:39 <ad_rien_> we can follow the proposed order or change a bit
15:08:58 <ansmith> To go along with the scenarios, is there a general agreement on the definitions of terms?
15:09:10 <ad_rien_> not yet
15:09:14 <ansmith> e.g. what is the definition of region, site, edge, etc.
15:09:24 <ad_rien_> maybe I should mention that we are discussing with the NFV working group
15:09:44 <ad_rien_> about what can be a minimalist NVFi deployment
15:10:11 <ad_rien_> some folks from AT&T are taking part to the discussion
15:10:28 <foliveira> ETSI NFV IFA WG?
15:10:31 <ad_rien_> The first approach would be to have a central control plane and the data plane on the edge. Concretely
15:10:59 <ad_rien_> foliveira:  https://etherpad.openstack.org/p/ops-telco-nfv-meeting-agenda
15:11:01 <ad_rien_> #link https://etherpad.openstack.org/p/ops-telco-nfv-meeting-agenda
15:11:02 <Menthos> Hi everyone
15:11:58 <ad_rien_> so the idea is to put keystone, glance, nova (main services), … in one ''central'' DC and put the nova-compute at the edge (i.e. on distinct location)
15:12:25 <ad_rien_> this is a first scenario where we can conduct functional and performance evaluations to see pros/cons
15:12:42 <ad_rien_> we should try to identify two or three more deployment scenarios
15:13:11 <ad_rien_> and for each identify pros/cons in terms of features and performances avantages/drawbacks
15:13:44 <ad_rien_> so maybe ansmith you are right we should define that in one document/pad
15:13:49 <ad_rien_> just to avoid confusion.
15:14:32 <ad_rien_> #action make a proposal for defining the different terms (region, site, edge, fog…)
15:14:47 <ansmith> attempt to unify definitision across openstack, etsi/nfv and edge/fog would be helpful
15:15:06 <ad_rien_> yes exactly
15:15:14 <ad_rien_> so let's try to identify what can be the key word:
15:15:24 <ansmith> and what functionality is expected of the "edge"
15:15:46 <ad_rien_> it depends the scenario but you are right we can define one.
15:16:43 <ad_rien_> so what are the key terms we may use ?
15:16:55 <ad_rien_> Region, edge, site, compute_node/hypervisor
15:17:02 <ansmith> cell
15:17:39 <ad_rien_> (ansmith BTW not sure how the cell V2 feature is going to progress as lasky left Mirantis)
15:17:55 <ansmith> maybe it is a term we should abstract away
15:18:18 <ad_rien_> we got an information from DinaBelova from the performance WG that told us it will be now manage by two persons at redhat (if I'm right)
15:19:22 <ad_rien_> There is another person at redhat that is also interested by this notion of fog/edge computing, maybe we should try to invite him
15:19:34 * ad_rien_ is looking for his name
15:20:27 <rcherrueau> There is someone from redhat that made a presentation on mobile edge computing. His name is Sanjay Aiyagari.
15:21:13 <rcherrueau> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17407/red-hat-mobile-edge-computing-in-support-of-iot
15:21:44 <ad_rien_> ansmith:  kgiusti do you know him ?
15:22:26 <ansmith> yes and we caught up with him in Barcelona
15:22:50 <ansmith> we have a follow up action to engage on nfv/iot topics with him
15:22:54 <ad_rien_> ok maybe it can make sense to have him to make progress on these definitions
15:23:23 <ad_rien_> getting back to the terms we should add in the list (see pad line 46)
15:23:26 <ad_rien_> anything else?
15:24:10 <ad_rien_> foliveira:  do you have a specific use-case in mind at Verizon ?
15:26:05 <ad_rien_> ok
15:27:01 <ad_rien_> ok
15:27:23 <ad_rien_> ansmith:  kgiusti do you have a deployment scenario in mind  to test QPID
15:27:35 <ad_rien_> I mean in terms of how deploying the different openstack services
15:27:59 <ad_rien_> (ie. considering only the core ones: keystone, glance, nova, neutron, horizon and cinder)
15:29:28 <kgiusti> At this point we're working with some of the downstream RDO folks in redhat to determine just that.
15:29:45 <ad_rien_> as I said I think we should try to identify at least two other scenarios
15:30:33 <ad_rien_> RDO  ?
15:30:49 <kgiusti> We need to identify those deployments that represent a challenge for a single/cluster broker
15:30:59 <ad_rien_> ok
15:30:59 <rbowen> http://rdoproject.org - a packaging of OpenStack for RPM.
15:31:17 <ad_rien_> #link http://rdoproject.org/
15:31:17 <kgiusti> RDO is the downstream community openstack release sponsored by redhat
15:31:30 <kgiusti> think fedora for openstack :)
15:31:36 <ansmith> thinking about the first scenario (e.g. central DC) there may be scenarios 1A and 1B
15:31:45 <ad_rien_> yes please go ahead ?
15:32:07 <ansmith> 1A which is hub and spoke, e.g. edge always goes back to central
15:32:17 <ansmith> 1B where edges have peer relations
15:32:47 <ad_rien_> to have peer relations, does it mean you have services deployed at the edge ?
15:32:49 <ansmith> 1B takes into account network communication topology as opposed to control path topology
15:32:57 <ansmith> yes
15:33:06 <ad_rien_> because AFAIK, compute nodes do not interact each other?
15:33:22 <ansmith> no but there may be networking service chains that link them up
15:33:40 <ad_rien_> can you elaborate a bit please
15:33:52 <ad_rien_> in 1A all control plane is within the DC
15:34:15 <ad_rien_> and compute_nodes at the edge (in different locations)
15:34:16 <ansmith> If I have network functions deployed as VMs at the edge, I would want to create network paths
15:34:17 <ad_rien_> in 1B?
15:34:35 <ad_rien_> ok
15:34:43 <ansmith> that would not want to be constrained by "hub n spoke'
15:34:45 <foliveira> I would expect that compute nodes would communicate within a site but perhaps not between sites.   Is this 1B as well?
15:35:03 <ansmith> I think it is a question for NFVi folks to see if this is implied by there scenario
15:35:10 <ad_rien_> ok
15:35:22 <ad_rien_> but in that case it looks to be communications between VMs (i.e. data plane)
15:35:30 <ad_rien_> is it correct ?
15:35:39 <persia> Consider the case where a "site" consists of several buildings on a campus, with a few nodes per building.
15:36:13 <persia> (or more widespread, but the campus model is fairly easy to map to a DC-focused model)
15:36:14 <foliveira> VxLAN tunnels between compute nodes?
15:36:43 <ad_rien_> persia:  ok ?
15:37:03 <ansmith> I read scenario above to imply edge is at a distinct location
15:37:52 <ansmith> potentially large latencies from DC to edge, expected outages, etc.
15:38:01 <ad_rien_> yes
15:38:26 <ad_rien_> this is the scenario 1A (I'm trying to make an ascii figure in the pad)
15:38:31 <jaypipes> y'all should just rename "massively distributed cloud working group" to "Telco/NFV workgroup"
15:38:53 <ad_rien_> thanks jaypipes :-)
15:39:40 <ad_rien_> but actually this is a bit different as massively distributed cloud is a bit larger than NFV (even if it is true that telcos operators are quite interested by the distribution of OpenStack)
15:39:59 <jaypipes> and yes, dansmith and melwitt from nova are continuing alaski's work in cellsv2
15:41:29 <ad_rien_> ansmith:  scenario  1A is in the pad
15:41:47 <ad_rien_> what was your idea of 1B?
15:42:24 <ad_rien_> what we would like to do by evaluating the performance of scenario 1A is to identify latency/bw limitations
15:42:55 <ad_rien_> another scenario can be to evaluate the region deployment scenario (as described in the OpenStack documentation)
15:43:17 <msimonin> scenario 1A seems similar to Nectar deployment where each location is a cell mapped to an availibilty zone ?
15:43:58 <ad_rien_> in 1A you have only compute nodes in remote locations
15:44:30 <ad_rien_> in the nectar approach, they follow the cell v1 approach so you have some controller services in each location
15:45:36 <ad_rien_> let's move forward
15:45:48 <ad_rien_> #action try to prepare figures to illustrate the different scenarios
15:46:14 <ad_rien_> so for the moment we have identified three scenarios
15:47:39 <msimonin> actually the scenario 1B proposed by ansmith is unclear to me
15:48:25 <ansmith> if VNF1 instance is at B and VNF2 instances is at C
15:48:38 <ad_rien_> yes?
15:48:42 <ansmith> scenario 1A implies they rely on A for network services
15:48:56 <msimonin> what do you mean?
15:49:02 <ansmith> scneario 1B would imply there are peer services at B and C
15:49:16 <msimonin> in 1A instances can communicate between location using tunnels ? no ?
15:49:25 <ansmith> to support optimal service chaining
15:49:51 <ad_rien_> I get the feeling that it depends how you are managing the network
15:49:54 <ad_rien_> (flat, ….)
15:50:18 <ad_rien_> if you are in the same domain, once the VMs (NFV instance) get their IPs, they can discuss directly
15:50:43 <ad_rien_> (this is a naive example just to check we are on the same wavelenght?)
15:51:35 <ad_rien_> from my understanding this is a drawback/limitations of the scenario 1A.
15:51:39 <ansmith> same wavelength, need to think through some more in the scenario spec
15:51:45 <ad_rien_> ok
15:52:03 <ad_rien_> So just to be sure, with the vanilla code, is there other possible scenarios ?
15:52:54 <ad_rien_> once again, the objective is to identify pros/cons of each approach, missing features, performance limitations...
15:53:33 <ad_rien_> based on that we can have stronger arguments to discuss with the openstack community and see what revisions/extensions can be proposed
15:53:42 <ad_rien_> is it ok for everyone?
15:54:05 <ad_rien_> of we have 5 min
15:54:14 <ad_rien_> more
15:54:40 <ad_rien_> I propose to switch to the open discussion as the other points are still related to the deployment scenarios
15:54:53 <ad_rien_> #topic Open Discussion
15:55:16 <ad_rien_> so on our side as mentioned we would be happy to get in touch Sanjay Aiyagar
15:55:35 <ad_rien_> would it be possible ansmith / kgiusti to introduce our WG?
15:56:02 <ansmith> we will reach out to Sanjay and invite him to participate as well
15:56:07 <ad_rien_> thanks
15:56:23 <ad_rien_> we should have a discussion with Deutch telekom next fridau on our side too
15:56:33 <ad_rien_> will keep inform about the results
15:56:42 <ad_rien_> that's all for the Inria side
15:56:43 <ad_rien_> Others ?
15:57:29 <ad_rien_> Ok it seems that we are done
15:57:57 <ad_rien_> I will clean the pad, please give it a look to see the actions we defined
15:58:13 <ad_rien_> and feel free to complete/amend it
15:58:18 <ad_rien_> thanks
15:58:32 <ad_rien_> For attending the meeting
15:58:44 <msimonin> thanks :)
15:58:49 <ad_rien_> #endmeeting