15:00:18 <ad_rien_> #startmeeting massively_distributed_clouds
15:00:19 <openstack> Meeting started Wed Feb 15 15:00:18 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <openstack> The meeting name has been set to 'massively_distributed_clouds'
15:00:24 <ad_rien_> #chair ad_rien_
15:00:31 <openstack> Current chairs: ad_rien_
15:00:43 <ad_rien_> #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 agenda line 185
15:01:13 <jamemcc> Hi Adrien
15:01:17 <ad_rien_> Hi all
15:01:21 <rcherrueau> o/
15:01:36 <ad_rien_> ping ad_rien_, msimonin, denaitre, dsantoro, menthos,  serverascode, jfpeltier, kgiusti, ansmith
15:01:47 <Menthos> o/
15:02:06 <kgiusti> o/
15:02:11 <ad_rien_> ok let's wait one more minute
15:02:11 <denaitre> o/
15:02:12 <mabderrahim> o/
15:02:12 <ansmith> o/
15:03:53 <ad_rien_> ok
15:04:23 <ad_rien_> so let's start (I was waiting additional folks from Orange but they will join us during the meeting hopefully)
15:04:47 <ad_rien_> #topic  Announcement
15:05:10 <ad_rien_> So from our side, only one news regarding the patch for Kolla that has been accepted
15:05:28 <ad_rien_> So we should be able to deploy multi regions by leveraging kolla soon.
15:05:46 <ad_rien_> #link https://review.openstack.org/#/c/431588/ kolla multi region support
15:06:03 <ad_rien_> There is one more patch to be accepted (please rcherrueau could you put the link)
15:06:34 * rcherrueau looking for the link
15:07:07 <rcherrueau> #link https://review.openstack.org/#/c/431658/
15:07:18 <ad_rien_> Thanks
15:07:53 <ad_rien_> finally we are working on the experiment plan for the first series of WAN evaluations (but we will discuss that point later).
15:08:00 <ad_rien_> So that's all from Inria side.
15:08:09 <ad_rien_> Anything else from your side guys ?
15:08:25 <jfpeltier> From Orange Rabbit Noise generator,
15:08:32 <ad_rien_> ok
15:08:39 <ad_rien_> do you want to discuss it now?
15:08:53 <ad_rien_> (@all please remind/feel free to contribute to the pad)
15:08:57 <jfpeltier> I have a tool allowing to send 400+ msg/s but no results with OpenStack
15:09:13 <jfpeltier> I don't have a presentation ready
15:09:44 <jfpeltier> I had to multi-thread it for performance and got some issues
15:09:57 <kgiusti> jfpeltier: is the tool available - open source?
15:10:12 <jfpeltier> It will soon be, yes
15:10:16 <ad_rien_> links?
15:10:22 <kgiusti> jfpeltier: sweet!
15:10:33 <jfpeltier> I did not put it on my github yet
15:10:54 <jfpeltier> It is based on the tool made by Ayeb, I'll send his link
15:11:02 <ad_rien_> ok
15:11:16 <ad_rien_> If I'm right we pushed the link last week.
15:11:49 <jfpeltier> yes https://github.com/abousselmi/osnoise
15:11:56 <ad_rien_> ok not that one ;)
15:11:57 <jfpeltier> sorry Ayoub
15:12:11 <ad_rien_> #link https://github.com/abousselmi/osnoise Orange contribution to stress the AMQP bus
15:12:47 <ad_rien_> ok
15:12:56 <ad_rien_> do you want to add something else?
15:13:15 <jfpeltier> nothing else from me
15:13:22 <ad_rien_> ok
15:13:34 <ad_rien_> anyone before switching to the next topic?
15:14:29 <ad_rien_> seems not
15:14:40 <ad_rien_> #topic  Deployment scenarios / WAN evaluations
15:15:02 <ad_rien_> As discussed our tool is now ready to emulate different network topologies
15:15:22 <ad_rien_> #link https://enos.readthedocs.io/en/latest/network-emulation/index.html Traffic shaping with ENOS
15:15:42 <ad_rien_> so we are currently working on the experiment methodology
15:16:01 <ad_rien_> I put some notes in the pad (with the support of rcherrueau and Menthos)
15:17:04 <ad_rien_> so we would like to perform two kinds of experiments the first one will be based on scenario 1 (i.e. control services deployed on one site and computes notes deployed on remote locations)
15:17:27 <ad_rien_> we are wondering whether you have some feedbacks/remarks regarding such an evalution?
15:17:42 <ad_rien_> What should be the latency/bandwith metrics we should emulate?
15:17:51 <ad_rien_> How many computes nodes per site?
15:18:00 <ad_rien_> is there a particular rally scenario to execute?
15:18:09 <ad_rien_> Any remark would be more than welcome ;)
15:18:30 <ad_rien_> jamemcc:  jfpeltier ?
15:18:53 <jfpeltier> well any measurement is interesting...
15:19:04 <Menthos> Why not just perform all of them and look at what fails? :-)
15:19:05 <jfpeltier> latency from 10ms to 200ms
15:19:36 <Menthos> (That's what I'm doing with other scenarios, it allows to turn on some red lights)
15:20:08 <jfpeltier> I don't think bandwidth is so much an issue
15:20:51 <ad_rien_> ok
15:21:20 <ad_rien_> because we are not a cloud provider/network operator, we are just wondering what can be the representative topologies?
15:21:45 <ad_rien_> so any remarks/feedbacks from cloud providers/telcos would be highly appreciated.
15:21:58 <ad_rien_> I will try to discuss this point next week with telcos.
15:22:36 <ad_rien_> Ok the second experiment will focus on the multi regions use-case
15:23:12 <ad_rien_> although this will be addressed after the first series of experiments, we would like to start the braimstorming sessions and get ideas/feedbacks as well?
15:24:02 <ad_rien_> jamemcc: I know that ATT solution is based on this idea of having independent Openstack on each site and a glue that provides a unified view.
15:24:12 <matrohon> ad_rien_, do you still use the nova fake driver?
15:24:27 <rcherrueau> yes we still use it
15:24:51 <ad_rien_> While preparing this meeting, we discussed whether this is the right way to go or not.
15:25:02 <rcherrueau> Do you think it's a big issue for the tests we envision?
15:25:28 <ad_rien_> ok let's make a pause on the multi region discussion.
15:25:43 <matrohon> the fake driver is not using nova-compute to neutron communications
15:25:45 <ad_rien_> matrohon: what do you have in mind?
15:25:46 <matrohon> AFAIR
15:26:18 <matrohon> I'm afraid we're missing some RPC call made by real drivers
15:26:31 <matrohon> not sure about that, need to check
15:26:38 <Menthos> matrohon: I think you're right
15:26:48 <ad_rien_> ok so this is an interesting point.
15:26:52 <Menthos> Have you looked at our presentation at the last summit?
15:26:57 <rcherrueau> matrohon: Good remark
15:27:03 <Menthos> Mirantis used a modified libvirt driver instead
15:27:12 <ad_rien_> Maybe we can use remove the fake drivers from this picture?
15:27:30 <matrohon> Menthos, which eumulates real calls?
15:27:30 <ad_rien_> I mean since we are not targetting the scalability in this experiment, we can use real nodes?
15:27:55 <ad_rien_> I mean the number of  remote sites is probably the main issue?
15:28:18 <Menthos> matrohon: from what I understood, they took the libvirt driver and just removed the calls to the hypervisor
15:28:30 <Menthos> So I think it was vanilla Neutron
15:28:43 <matrohon> ok, so neutron did the plumbing job
15:28:56 <rcherrueau> matrohon: Mirantis solution uses a modified libvirt that doesn't start vms
15:29:11 <matrohon> rcherrueau, sounds more realistic
15:29:11 * Menthos looking for a link
15:29:57 <matrohon> cinder should be impacted too if VMs have volume attached
15:30:08 <ad_rien_> yes
15:30:22 <ad_rien_> so we need to evaluate a scenario that include cinder volumes
15:30:30 <Menthos> Foud it: https://youtu.be/XURkQ3biF6w?t=10m6s
15:30:56 <matrohon> Menthos, thanks
15:30:58 <ad_rien_> #link https://youtu.be/XURkQ3biF6w?t=10m6s Mirantis explain the fake driver issue
15:31:53 <ad_rien_> getting back to cinder, we can have a cinder per site
15:32:07 <ad_rien_> but this is true that right now we never dive into cinder considerations
15:32:08 <Menthos> rcherrueau: notifies me that my link broke his Emacs, so he can't speak anymore
15:32:43 <ad_rien_> So that leads us to my initial question: what can be the right scenarios to evaluate?
15:32:49 <Menthos> rcherrueau says Inria haven't had a look at Cinder yet (only Nova, Keystone and Neutron)
15:32:59 <ad_rien_> There are a lot of components/services, I don't know whether we can evaluate all of them.
15:33:15 <ad_rien_> ok
15:33:17 <matrohon> agreed
15:33:22 <ad_rien_> anything else.
15:33:32 <ad_rien_> Can we move to the region use-case?
15:33:59 <matrohon> I think we should stick to simple scenario first : VMs attached to providers net with no volumes
15:34:12 <ad_rien_> yes that was indeed the initial idea
15:34:21 <ad_rien_> then complexifies the picture by adding cinder volumes
15:34:29 <Menthos> +1
15:34:35 <ad_rien_> by checking live migrations from one remote compute to another one (intra and inter sites)
15:35:00 <Menthos> Yes the rally scenarios for live migrations are a good way to start testing cinder
15:35:45 <ad_rien_> So getting back to the multi region scenario
15:36:06 <ad_rien_> we are not convinced that this is the right direction
15:36:31 <ad_rien_> We are wondering actually why the region abstraction has been proposed?
15:36:42 <ad_rien_> This is another way to segregate an infrastructure
15:36:58 <ad_rien_> but there is the cell abstraction
15:37:29 <matrohon> every big cloud provider (amazon ahead) is providing multi-region
15:37:57 <ad_rien_> matrohon:  you mean availability zone, don't you?
15:38:49 <ad_rien_> i.e. with the multi region there is a strong segregation. For instance you should run a unique/common keystone
15:39:05 <ad_rien_> if you want your users to be able to run VM on every site
15:39:09 <ad_rien_> every region (sorry)
15:39:19 <matrohon> i don't know the name at amazon... but I think one need to choose a regino to get endpoint it will work with am i wrong
15:39:34 <jfpeltier> to link both aspects, you need additional filters in nova-cheduler
15:39:37 <ad_rien_> so this mean that either you have a global keystone or you have several keystone and a mean to federate them.
15:40:37 <ad_rien_> jfpeltier:  that's exactly my point, I have the feeling that on the first hand you are segregating your infrastructure into several regions (i.e. independent openstack) but then you need additional pieces of software to federate them
15:40:44 <jfpeltier> adrien in your use-case, do you have unique database?
15:40:47 <ad_rien_> ….. this looks weird, doesn't it?
15:40:52 <ad_rien_> not yet
15:41:00 <ad_rien_> for the moment, we only work with the vanilla code
15:41:25 <ad_rien_> we would like to identify all issues that prevent the use of one technology/solution
15:42:08 <ad_rien_> jfpeltier:  not yet was the answer of your question (sorry for not beeing clear)
15:42:58 <jfpeltier> We tried both configurations, unique database allows more fetures but also has some drawbacks
15:43:17 <matrohon> if you look at ongoing deployments with multi-region, they all have a piece of software to aggregate those regions
15:43:26 <jfpeltier> I guess the normal one is to segragate
15:43:31 <ad_rien_> matrohon: such as?
15:43:41 <matrohon> ATT is using ecomp for instance
15:43:52 <ad_rien_> yes that was the question to jamemcc?
15:43:54 <matrohon> an ochetsrator on top of regions
15:44:07 <ad_rien_> but this mean you have to developp/maintain such a component
15:44:16 <matrohon> indeed
15:44:28 <ad_rien_> in somehow, you use openstack as libvirt
15:44:52 <ad_rien_> so it means that you have to redevelop most of services (for instance a scheduler, ...)
15:45:03 <ad_rien_> this looks like the initial TriCircle proposal
15:45:15 <matrohon> yep
15:45:32 <ad_rien_> The question that would be great to answer is what are the right arguments to justify such an approach
15:45:47 <ad_rien_> I guess that they think about it before implementing such an orchestrator
15:45:52 <matrohon> independant failure domain
15:45:58 <ad_rien_> in the sense ?
15:46:14 <ad_rien_> is there a ecomp presentation somewhere available?
15:46:26 <ad_rien_> jamemcc, still there? do you have such a pointer?
15:46:28 <matrohon> workloads in one failing openstack can move to another openstack
15:46:59 <jamemcc> Yeah
15:47:05 <ad_rien_> ok maybe we can put this question on the pad and discuss it next time
15:47:23 <jamemcc> I'll look and see if I can find a link before end of meeting.  If not will send e-mail.
15:47:27 <ad_rien_> jamemcc? What do you prefer?
15:47:51 <ad_rien_> from my point of view, the advantages is that ecomp can operate whatever cloud systems
15:47:56 <matrohon> ecomp should be opensource source, jamemcc, is it already?
15:48:06 <matrohon> s/source/soon
15:48:12 <jamemcc> Next meeting would be great - I can probably arrange to have appropriate architect
15:48:13 <ad_rien_> (i.e. not just OpenStack but all clouds that are openstack compliants)
15:48:18 <ad_rien_> great
15:48:30 <ad_rien_> I think this is an important point to clarify because
15:48:48 <ad_rien_> it will help us to justify either a top/down or a bottom/up approach
15:48:54 <jamemcc> I'll have to loko for specific status - which license Mathieu.  I'll include that as well.
15:49:01 <ad_rien_> great
15:49:19 <ad_rien_> (ten minutes before the end of the meeting, I propose to switch to the next point)
15:49:20 <jamemcc> Certainly is the intent and we've announced the intent.
15:50:41 <ad_rien_> #topic F2F meeting in Boston
15:51:26 <ad_rien_> I will open an etherpad so we can keep up-to-date informations related to Boston. Who will be there? What are the points we would like to discuss? etc..
15:51:48 <ad_rien_> Since I didn't do this pad yet, I propose to discuss it next week.
15:51:48 <ad_rien_> Ok ?
15:52:04 <ad_rien_> #action ad_rien_ Create a pad for Boston F2F meeting
15:53:00 <ad_rien_> ok so let's move to the open discussion moment
15:53:04 <ad_rien_> #topic open discussions
15:53:11 <ad_rien_> so please guys the floor is yours
15:54:11 <denaitre> we have looked on the different solutions used to deploy openstack
15:54:35 <denaitre> more particularly kolla, enos, juju, kuberneted and tripleo
15:55:39 * denaitre looking for a link
15:56:47 <kgiusti> I'd like to discuss https://docs.google.com/presentation/d/1ghwinrArfoCw1qIsNGxWSrd8NTynYomThERGUpN4f0U/edit?usp=sharing *before* boston if possible
15:56:53 <denaitre> https://goo.gl/7IksQY
15:57:02 <kgiusti> next meeting?  Just a real quick run through.
15:57:15 <ad_rien_> #link https://goo.gl/7IksQY how deploying OpenSTack in a massively distributed context
15:57:25 <ad_rien_> kgiusti:  yes I will add it to the agenda
15:57:29 <kgiusti> thanks
15:57:31 <ad_rien_> as one item
15:58:03 <ad_rien_> [ ] ad_rien_ put the AMQP discussion as a main point for the next meeting.
15:58:13 <ad_rien_> #action ad_rien_ put the AMQP discussion as a main point for the next meeting.
15:58:19 <ad_rien_> Ok I propose to close the meeting
15:58:28 <jfpeltier> ok
15:58:35 <ad_rien_> ok so talk to you in two weeks
15:58:39 <ad_rien_> thanks for attending the meeting
15:58:47 <ad_rien_> #endmeeting