15:02:10 <ad_rien_> #startmeeting massively_distributed_clouds
15:02:11 <openstack> Meeting started Wed Nov 22 15:02:10 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:02:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:14 <openstack> The meeting name has been set to 'massively_distributed_clouds'
15:02:20 <ad_rien_> #chair ad_rien_
15:02:21 <openstack> Current chairs: ad_rien_
15:02:29 <ad_rien_> #topic roll call
15:03:00 <ad_rien_> so sorry for the delay, I'm attending a conference and I need to find a more peaceful location.
15:03:32 <ad_rien_> So don't know how many people will be there today (thanksgivings week)
15:03:35 <ad_rien_> so let's see
15:03:38 <ad_rien_> o/
15:03:50 <oanson> o/
15:03:50 <msimonin1> hey o/
15:04:08 <ad_rien_> so Three ;)
15:04:10 <alex__> hi
15:04:13 <ad_rien_> anyone else
15:04:14 <ad_rien_> ?
15:04:22 <rcherrueau> o/
15:04:37 <lihi> o/
15:04:42 <irenab> ין
15:05:40 <ad_rien_> ok
15:05:50 <ad_rien_> #info agenda
15:06:10 <ad_rien_> #link https://etherpad.openstack.org/p/massivfbely_distributed_ircmeetings_2017 line 1484
15:07:04 <ad_rien_> so before starting may I ask to the new folks who they are? and what are your expectactions with respect to the FEMDC SiG
15:07:04 <ad_rien_> ?
15:07:43 <msimonin> #link https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 line 1484
15:07:53 <msimonin> (one typo in the above link)
15:08:15 * irenab working both on Dragonflow ad Kurryr projects, here to understand better the use cases and requirements
15:08:27 <ad_rien_> cool
15:08:32 <ad_rien_> welcome irenab
15:08:33 <msimonin> welcome irenab
15:08:44 <oanson> I'm new. I was in the Sydney Summit workgroup meeting and would like to hear more info. I'm also on the Dragonflow project.
15:09:00 <msimonin> welcome oanson :)
15:09:26 <ad_rien_> great to see more folks
15:09:36 <ad_rien_> and If I'm correct lihi ?
15:09:45 <lihi> Yes :)
15:09:52 <lihi> Also working on Dragonflow. I've been in your session at the summit, and would love to hear more
15:10:27 <ad_rien_> ok
15:11:01 <ad_rien_> So we are used to work with the etherpad (as usual in the OpenStack community). Please feel free to comment or add questions directly in the pad
15:11:11 <ad_rien_> msimonin copied the link and the line
15:11:50 <ad_rien_> any question before starting ?
15:11:59 <irenab> no
15:12:14 <ad_rien_> #topic announcement
15:12:14 <oanson> None here.
15:12:26 <ad_rien_> so I don't not have too many information to share today
15:12:44 <ad_rien_> as I said this is the thanksgivings week and more of our US folks are on vacations.
15:12:57 <ad_rien_> Maybe two points (already noticed in the pad)
15:13:08 <ad_rien_> First there is a new mailing list that has been created by the OpenSTack foundation
15:13:19 <ad_rien_> I do not have additional information but the one I shared on the pad
15:13:46 <ad_rien_> I sent an email to the foundation to try to clarify what are the objectives of this new ML and the envisioned working sessions that have been highlighted in the invitation
15:14:23 <ad_rien_> the second point is related to the latest document AT&T did on the edge computing
15:14:37 <ad_rien_> I put the link in the pad too
15:15:39 <ad_rien_> Last but not the least, dpertin is still on vacations so we do not debrief yet regarding the summit
15:15:44 <msimonin> #link http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing
15:16:06 <ad_rien_> The only information I have is that there were several sessions dealing with edge computing challenges.
15:16:26 <ad_rien_> I hope dpertin or parus will be able to share important feedbacks during the next meeting.
15:16:30 <ad_rien_> So that's all from my side.
15:16:40 <ad_rien_> Any news to share ?
15:16:43 <irenab> I also saw the Use Cases doc. Is there any recording of the presentation?
15:17:01 <ad_rien_> the session chaired by Beth (verizon)?
15:17:22 <irenab> not sure, Telco Edge use cases
15:17:51 <ad_rien_> AFAIK, we are still working on the white paper (we expect to release it by the end of the year).
15:18:00 <irenab> https://docs.google.com/presentation/d/1pAAdrzn1kgQCCAffdngiE-NvzsDn8sN4Uj6NFV6NgjQ/edit#slide=id.p4
15:18:04 <ad_rien_> there are still some points that need to be clarified in particular on the requirements
15:18:53 <irenab> so is this going to be discussed during the next meetings?
15:18:58 <ad_rien_> regarding to these slides. I think it is preferable to wait for parus (paul-andre) for the next meeting
15:19:05 <ad_rien_> irenab:  yes ;) ?
15:19:11 <irenab> thanks!
15:19:13 <ad_rien_> Paul-André is chairing this action.
15:19:36 <ad_rien_> #action Paul-Andre should give us feedbacks on his presentation
15:19:48 <irenab> I thought maybe it was presented in Sydney
15:20:48 <ad_rien_> yes it has been presented as a lighting talk
15:20:49 <msimonin> this maybe : https://www.openstack.org/videos/sydney-2017/telco-use-cases-for-massively-distributed-edge-clouds
15:20:52 <ad_rien_> If I'm right
15:21:10 <ad_rien_> msimonin:  yes thanks
15:21:12 <irenab> msimonin: thanks
15:21:46 <ad_rien_> #topic on-going actions - Use-cases
15:22:01 <ad_rien_> can be better as we already started to discuss about use-cases
15:22:06 <ad_rien_> is there anyone from FBK ?
15:22:46 <ad_rien_> I don't think so...
15:22:55 <ad_rien_> so the meeting would probably be shorter today .
15:24:04 <ad_rien_> ok so I guess that we neither have folks from ericsson unfortunately ?
15:24:40 <msimonin> It seems it's Inria/Dragonflow meeting :)
15:25:02 <ad_rien_> ok so we can probably change the agenda ?
15:25:12 <ad_rien_> I mean this can be more fruitful for everyone?
15:25:21 <msimonin> yes probably
15:25:34 <ad_rien_> The agenda has been updated with enough information from my viewpoint regarding current status of on-going actions
15:25:50 <ad_rien_> if this is ok for everyone, we can maybe try to answer the questions you may have
15:26:06 <msimonin> We can have a pass on the two actions AMQP and cockroach ?
15:26:12 <ad_rien_> so irenab lihi oanson ?
15:26:17 <ad_rien_> as you want
15:26:28 <ad_rien_> so let's do a brief pass on cockroach and AMQP
15:26:36 <msimonin> ok
15:26:47 <ad_rien_> and then let the floor to DragonFlow folks ?
15:26:49 <msimonin> I can try to sum up these with rcherrueau
15:26:53 <msimonin> yes let's do this
15:26:55 <ad_rien_> please
15:27:08 <ad_rien_> #topic on-going action - cockroach -
15:27:57 <ad_rien_> so rcherrueau ?
15:27:59 <rcherrueau> May I put the general idea for dragon flow folks?
15:28:03 <ad_rien_> sure
15:28:11 <ad_rien_> or the other way ?
15:28:26 <ad_rien_> no, please go on rcherrueau
15:28:33 <rcherrueau> When you look at OpenStack services there are two components that don't scale
15:28:48 <rcherrueau> the message bus and the database
15:29:07 <rcherrueau> you know that, for sure, because dragon decided to change the database backend
15:29:25 <oanson> Yes. Also the message bus was changed
15:29:34 <msimonin> oanson: ah !
15:29:55 <rcherrueau> at dragon flow, you decided to go with a NoSQL database (if I remember correctly)
15:30:04 <irenab> rcherrueau: right, no need for AMQP
15:30:31 <oanson> Yes. We use a distributed key-value store. We use a pub/sub mechanism on top of that, so messages are passed with less overhead.
15:30:46 <rcherrueau> Going with a NoSQL database, is a good option, but you have to re-implement all queries
15:31:01 <irenab> but this resolves the networking part, there arestill other openstack services that require them
15:31:20 <rcherrueau> yes, some openstack services really need a sql database
15:31:42 <rcherrueau> or, at least, a database that implements the sql semantic
15:31:43 <oanson> rcherrueau, we re-wrote the entire db model (for better or for worse)
15:32:05 <rcherrueau> And here come NewSQL databases
15:32:33 <rcherrueau> NewSQL databases are SQL databases that are distributed and scale out
15:32:51 <rcherrueau> and also implements the sql semantics
15:33:09 <irenab> I am still learning about this group objectives, so correct me if I am wrong. You are looking to resolve more than networking part. Resolve general Edge<->DC/Cloud use case. right?
15:33:24 <rcherrueau> (ACID properties and transactions work like in a centralized sql database)
15:34:16 <rcherrueau> For my side, I am looking at making some OpenStack services (keystone, nova) work on top of CockroachDB (a NewSQL database)
15:34:27 <ad_rien_> irenab:  yes ?
15:34:34 <ad_rien_> s/yes ? /yes !
15:34:36 <ad_rien_> sorry
15:34:37 <msimonin> irenab: yes, the ultimate goal
15:34:42 <rcherrueau> to get a collaboration with many instances for free
15:34:55 <ad_rien_> the goal is to revise OpenStack core-services to be able to operte fog/edge infrastructures
15:35:05 <ad_rien_> so the first challenge is to deal with scalability/distribution issue
15:35:06 <rcherrueau> since the will all share the same state
15:35:20 <ad_rien_> as rcherrueau said the DB and the communication bus are the first challenge to address
15:35:47 <ad_rien_> (then you have to deal with efficient management of VM images, network issues related to cross domain, i.e. tricircle like proposals…)
15:36:03 <ad_rien_> sorry rcherrueau please go on (I hope I clarified your question irenab )
15:36:20 <irenab> ad_rien_: agree, it is challenging enough in large single data center, so can imagine once distributed across many PoPs
15:36:39 <ad_rien_> actually the first experiments we made are encouraging
15:36:42 <ad_rien_> ;)
15:36:57 <ad_rien_> but rcherrueau and msimonin can say more
15:37:29 <rcherrueau> So, regarding the support of CockroachDB we now passes all migrations during the deployment of keystone and nova
15:38:23 <rcherrueau> Which means you can go with devstack, then define CockroachDB as db backend, and the deployment phase will be successful
15:38:39 <rcherrueau> Queries works for Keystone
15:38:50 <rcherrueau> but some don't work for nova
15:39:11 <rcherrueau> Queries that don't work for nova are "correlated subqueries"
15:39:25 <rcherrueau> #link https://en.wikipedia.org/wiki/Correlated_subquery
15:40:14 <rcherrueau> We have some option here: (i) changing nova code for our PoC, (ii) trying to rewrite the query in the SQLAlchemy-dialect, ...
15:40:28 <rcherrueau> Don't know if you wanna speak about that right now?
15:41:19 <irenab> I do not think I can contribute much here, so up to you
15:41:27 <rcherrueau> Anyway, if you have any questions regarding the db part, don't hesitate.
15:42:04 <rcherrueau> irenab: actually my question was for ad_rien_
15:42:21 <ad_rien_> sure ?
15:42:37 <ad_rien_> sorry
15:42:58 <ad_rien_> maybe msimonin can give an overview of AMQP work
15:43:02 <msimonin> sure
15:43:05 <ad_rien_> and then we can let the floor for the discussion ?
15:43:09 <msimonin> sure
15:43:25 <rcherrueau> ad_rien_: Do you want me to tell the pro and cons of the different options to implement correlated subqueries, or shall we continue?
15:44:13 <msimonin> IMHO we should keep the details for later
15:44:13 <ad_rien_> I propose to go on with the AMQP solution
15:44:16 <ad_rien_> yes
15:44:23 <ad_rien_> I think it is better
15:44:33 <ad_rien_> because this is a first introduction to what we are doing in the SiG
15:44:44 <ad_rien_> #topic on-going action - AMQP -
15:44:53 <rcherrueau> sounds good to me
15:44:55 <ad_rien_> please @msimonin can you give a short overview
15:45:00 <msimonin> So, porting the state management to cockroach is one action of the group here
15:45:11 <msimonin> another action is to look at the message bus
15:45:34 <msimonin> in the context of openstack services spread accros several sites
15:45:36 <ad_rien_> WANwide (i.e. not only in terms of scalability but in terms of Wide Area Network)
15:46:04 <msimonin> the action is sumed up in the review  :
15:46:13 <msimonin> #link https://review.openstack.org/#/c/491818/
15:46:45 <msimonin> I would sum up this by saying we are evaluating both the transport protocol but also the patterns used by the different services
15:47:04 <msimonin> Don't hesitate to have a look :)
15:47:10 <ad_rien_> :-) this is a rather effective summary ;)
15:47:13 <ad_rien_> thanks
15:47:54 <msimonin> Just to make things clearer these are not the only actions of the group :)
15:47:54 <ad_rien_> so I would like to ask some questions regarding one particular scenario to the DragonFlow folks?
15:47:56 <ad_rien_> May I ?
15:48:22 <ad_rien_> irenab:  oanson lihi ?
15:48:23 <lihi> Sure
15:48:30 <ad_rien_> #topic openDiscussions
15:48:51 <ad_rien_> One one the easiest scenario to operate a fog/edge infrastructure (ie. several sites that are geographically spread)
15:48:59 <ad_rien_> is to let the control plane in one DC
15:49:08 <ad_rien_> and then only operate remote compute nodes (so far so good) ?
15:49:45 <ad_rien_> The question is quite simple, will such a deployment benefit from DragonFlow (i.e. in terms of messages between compute nodes and dragonflow controllers)?
15:49:56 <ad_rien_> (in comparison to the vanilla Neutron)
15:50:15 <ad_rien_> Please do not hesitate to ask me additional questions if I'm not clear enough
15:51:06 <oanson> We think so. Firstly, the controller is very close to switch. This way, it can detect faults more accurately (less false positives/negatives)
15:51:34 <ad_rien_> (Hi ansmith,  the meeting is going to end if ten minutes ;) I though you were on vacations)
15:51:50 <ad_rien_> (we have a few folks from DragonFlow so we changed a bit the agenda)
15:51:53 <oanson> Secondly, Dragonflow works by pushing policies rather than flows to the nodes. We think this allows for better calculation according to local data.
15:52:14 <ansmith> no worries, sorry to be late
15:52:18 <ad_rien_> it would be great to see where will be the dragonflow components in such a deployment
15:52:38 <oanson> There are many options.
15:52:51 <ad_rien_> do you think one of you can prepare a slide to highlight where the components will be deployed (or if there is a pointer to give a look
15:52:52 <ad_rien_> )
15:53:01 <ad_rien_> the goal is to try to mitigate the traffic between DCs
15:53:04 <oanson> We definitely can.
15:53:23 <oanson> We're working on a PoC for something similar, so it could be beneficial for us as well
15:53:34 <ad_rien_> (i.e. the global one, i.e. the one where you will find nova, glance,  DBs, …. and the ones where you only have compute nodes)
15:53:49 <ad_rien_> yes I guess that this is also relevant in the case of a cell deployment
15:53:58 <ad_rien_> the idea is to mitigate the traffic between the different cells
15:54:05 <ad_rien_> (so far so good ?)
15:54:10 <oanson> But this is a different direction that cockroachdb and ampq
15:54:28 <ad_rien_> hmm...
15:54:31 <ad_rien_> not sure…
15:54:42 <oanson> Not mitigate the traffic so much as be more fault-tolerant
15:54:55 <ad_rien_> you can see cockroach as a noSQL system with the capability to write data locally
15:55:02 <ad_rien_> oanson:  agreed
15:55:06 <oanson> It's all right if the message doesn't make it. The database will eventually be updated, and eventually Dragonflow will see the change
15:55:22 <ad_rien_> we are working on a document to try to identify the pros/cons of different architectural choices
15:55:31 <ad_rien_> such as the ones you've just highlighted
15:55:32 <oanson> ad_rien_, yes. We're completely pluggable. Writing a cockroachdb driver would be no problem.
15:56:14 <msimonin> I think we aren't much familiar with dragonflow internals
15:56:15 <msimonin> and
15:56:30 <msimonin> oanson: what would be the first documents to read ?
15:56:52 <ad_rien_> oanson:  do you think you can give us an short overview (a few slides) that we can give a look to
15:56:59 <oanson> This is our blog: http://www.dragonflow.net/
15:57:20 <oanson> I note there's no introduction post. So I'll upload one tomorrow
15:57:26 <ad_rien_> of the advantages of DragonFlow in a fog/edge deployment such as the one I described (i.E. a master DC with most control plane services and remote compute nodes)?
15:57:34 <oanson> Yes, a few slides is possible.
15:57:47 <ad_rien_> it would be definitely awesome
15:57:56 <msimonin> +1
15:57:57 <ad_rien_> if you can do that for the next meeting (i.e. in two weeks)
15:58:18 <oanson> This is a presentation I gave in openstack days Turkey last month: https://docs.google.com/presentation/d/1w_TTYk1085SuiZ8R2qYoYdBugShGKntvz3EqPgKDosw/edit?usp=sharing
15:58:23 <ad_rien_> You can just add the link toward these slides on the pad just one day before so everyone can give it a look
15:58:31 <ad_rien_> (guys two minutes before the end of the meeting)
15:58:34 <msimonin> #link https://docs.google.com/presentation/d/1w_TTYk1085SuiZ8R2qYoYdBugShGKntvz3EqPgKDosw/edit?usp=sharing
15:58:42 <msimonin> just recording some links :)
15:58:47 <ad_rien_> Ok
15:58:50 <oanson> Sure. I'll make a more clear presentation as well.
15:58:58 <ad_rien_> May I propose to continue the discussion during the next meeting
15:59:04 <ad_rien_> I will add an item in the agenda for sure
15:59:08 <ad_rien_> great
15:59:14 <ad_rien_> so thanks everyone for joining the meeting
15:59:14 <oanson> Thanks!
15:59:20 <ad_rien_> if there is something special to discuss
15:59:22 <msimonin> Thanks
15:59:24 <ad_rien_> please add it into the pad
15:59:33 <ad_rien_> #endmeeting