09:00:20 <gsagie> #startmeeting dragonflow
09:00:21 <openstack> Meeting started Mon Jun 20 09:00:20 2016 UTC and is due to finish in 60 minutes.  The chair is gsagie. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:25 <openstack> The meeting name has been set to 'dragonflow'
09:00:30 <gsagie> Hello all, who is here for the Dragonflow meeting
09:01:09 <gsagie> ok..
09:01:19 <gsagie> it seems like this is going to be a short meeting :)
09:01:39 <gsagie> or i will just talk to myself
09:01:57 <oshidoshi> o/
09:01:58 <gsagie> so gal, what have you done this week
09:02:01 <gsagie> ohhhh!
09:02:05 <gsagie> oshidoshi :)
09:02:05 <gampel1> hi
09:02:13 <oshidoshi> where's the party
09:02:15 <gsagie> #info oshidoshi, gampel1, gsagie in meeting
09:02:17 * oshidoshi looking for cakes
09:02:19 <gsagie> Its party of 3
09:02:25 <gsagie> no one else came
09:02:35 <oshidoshi> oh, you poor thing
09:02:47 <gsagie> its ok, more cake for us
09:02:50 <oshidoshi> but everyone that *really* matters is here :)
09:02:51 <Duan> hi
09:02:58 <gsagie> hi Duan :)
09:03:06 <gsagie> #info Duan is in the meeting!
09:03:20 <gsagie> #topic open patches
09:03:26 <gsagie> nick-ma: here?
09:03:30 <gsagie> #info hujie in meeting
09:03:33 <nick-ma> yes
09:03:42 <gsagie> ohhh you were quiet :)
09:03:46 <yuval> hey
09:03:49 <gsagie> #info nick-ma is in the meeting
09:04:01 <nick-ma> i'm replying email, didn't notice irc. sorry.
09:04:27 <gsagie> np
09:04:34 <gsagie> #info The Brik is in the meeting as well
09:05:02 <gsagie> Duan, hujie, nick-ma: any open patches that we need to discuss about?
09:05:39 <hujie> the bug patch we discussed ?? :)
09:05:44 <Duan> liu haixia have two patches
09:05:48 <gsagie> hujie: want to describe it here?
09:05:55 <gsagie> Duan: can you please give links
09:06:04 <hujie> Both Li Ma and Duan know it
09:06:12 <oshidoshi> https://review.openstack.org/#/c/329806/
09:06:12 <Duan> one is about modifing the vxlan implemantation
09:06:24 <gsagie> hujie: its good for the log... and oshidoshi/gampel are not familiar
09:06:24 <hujie> if there are more important we could continue after the meeting :)
09:06:39 <gsagie> ok
09:06:44 <hujie> ok
09:06:44 <Duan> the other is add vlan support
09:07:06 <Duan> we need to review thest two patches.
09:07:07 <gsagie> Duan: VLAN support needs to change all applications right?
09:07:36 <gsagie> the L2
09:07:46 <gsagie> We are using the VLAN as the segmentation id?
09:07:50 <gsagie> Hello vikasc !
09:07:54 <Duan> only need to change l2 app and neturon plugin
09:07:54 <hujie> I have a remote port patch: https://review.openstack.org/#/c/328706/
09:07:55 <vikasc> hi gsagie
09:08:10 <gsagie> #link https://review.openstack.org/#/c/328706/ remote port patch
09:08:14 <vikasc> hello everyone
09:08:25 <nick-ma> hello
09:08:43 <gsagie> Duan: ok, we will review it
09:08:50 <hujie> the implement code I need to further modification :)
09:09:37 <gsagie> hujie: i havent read the design yet, but isnt it something we need support from Neutron API?
09:09:44 <gsagie> or you use the port binding profile for now?
09:09:53 <nick-ma> binding:profile
09:10:01 <hujie> yes
09:10:14 <gsagie> Are we trying to make it a "standard" in Neutron in anyway?
09:10:21 <gsagie> as in have a formal API
09:10:23 <Duan> no modification for neutron api are needed.
09:10:40 <gampel> hujie: who will populate the chassis table with the remote Host chassis
09:10:47 <hujie> we use the content of binding:profile
09:11:21 <nick-ma> +1 gsagie's suggestion. we can try to promote it to neutron.
09:11:28 <gampel> but we need to create the tunnel to that chassis
09:12:22 <hujie> we do not to publish a specific chassis create msg
09:12:31 <Duan> @gampel, the tunnel is created when first remote port is added.
09:12:32 <gsagie> for example, maybe you want to bind a whole subnet, instead of individual ports..
09:12:39 <hujie> we put the info in common create lport msg
09:12:57 <hujie> the tunnel port is created as Duankebo said
09:13:38 <gsagie> ok, lets review this patch again
09:13:38 <hujie> tunnel will be deleled when last remote port leave
09:14:01 <gampel> So it will be another tunnel creating procedure not via the "chassis" event
09:14:02 <hujie> the tunnel creation is dif from current implement
09:14:11 <hujie> yes
09:14:44 <Duan> it is created only when needed
09:15:31 <hujie> because we only know the port info, no one will notify the specific chassis, we should do it ourselves
09:15:47 <gampel> hujie: I agree with gsagie that we need a "standard" way as much as possible, if i remember correctly there was a remote port BP in neutron
09:16:49 <hujie> ok, we will learn it :)
09:17:12 <hujie> we could discuss other issues :)
09:17:13 <Duan> Hi Eran, we can discuss this topic in detail after the IRC
09:17:27 <gsagie> ok
09:17:33 <gampel> hujie: Ok
09:17:37 <gsagie> any other open patches that needs review?
09:18:20 <gsagie> #topic road map
09:18:31 <Duan> heshan has summit a l3 plugin patch
09:18:45 <gsagie> will take a look
09:18:45 <Duan> please help reviewing it if you have time
09:18:48 <nick-ma> it is marked as WIP
09:19:07 <nick-ma> is it working?
09:19:14 <gsagie> #link https://review.openstack.org/#/c/316785/
09:19:26 <gsagie> yes, tell him to remove WIP and add tests
09:19:28 <gsagie> please
09:19:34 <Duan> I have be completed, just need to update the title
09:19:58 <Duan> it works
09:19:58 <gsagie> and also, we need some example local.confs
09:20:01 <gsagie> for it
09:20:11 <Duan> ok, np
09:20:14 <gsagie> thanks
09:20:17 <gsagie> ok for road map
09:20:32 <gsagie> #link https://etherpad.openstack.org/p/dragonflow-newton
09:20:57 <gsagie> Any feedback on that? Duan we exchanged emails about LB
09:21:04 <gsagie> load balancing
09:21:19 <gsagie> and there is the QoS work
09:21:31 <gsagie> Is there any plans of what is the most urgent to work on?
09:21:40 <Duan> Yes LB is oure desired feature.
09:21:43 <yamamot__> are you going to replace the current plugin with ml2?  or are you going to maintain both of them for a while?
09:22:03 <Duan> QoS is under designing now,
09:22:10 <gsagie> yamamoto: i think the plan is to replace it with ML2 eventually, why?
09:22:37 <nick-ma> but I think at the current stage, we need to maintain both of them in at least one release cycle.
09:23:20 <yamamot__> gsagie: because how long we want to maintain both affects how desirable to share l3 code for the separate plugin
09:24:12 <gsagie> Duan: i think we need to understand what are the most important features and what features we can work together on the design
09:24:22 <gsagie> for example, we talked last meeting about working with nick-ma about DPDK
09:24:26 <gsagie> is there any progress there?
09:25:52 <gsagie> There are some missing features we wanted to add like provider networks ( i see availability zone but i dont think its really relevant for Dragonflow as this mainly talks about running agents)
09:26:23 <nick-ma> yes. provider networks.
09:26:50 <Duan> we plan to compete the basic features first
09:27:06 <Duan> for example, qos, ml2/l2 plugin
09:27:25 <Duan> and live migration
09:27:41 <gsagie> Duan: ok, for live migration is there any design?
09:27:54 <gsagie> is live migration working right now with DVR?
09:27:54 <Duan> not yes
09:28:08 <Duan> we are working on qos now
09:28:15 <gsagie> ok
09:28:21 <gampel> I am not sure live migration  is basic feature
09:28:22 <gsagie> qos using OVS queues?
09:28:32 <Duan> and HA and db consistency
09:28:54 <nick-ma> you mean redis HA?
09:28:57 <gampel> Duan: HA for redis
09:28:58 <nick-ma> or what?
09:29:01 <nick-ma> ok
09:29:02 <Duan> We will submit a spec about qos soon
09:29:18 <Duan> yes redis HA
09:29:48 <gsagie> ok thanks Duan, please let us know if you need any help with anything
09:30:02 <Duan> gal, yes, we plan to use ove queue
09:30:18 <Duan> but are open for other options.
09:30:22 <gsagie> We do want your team feedback about future features, for example if LB is important we can start thinking about it
09:30:31 <gsagie> but we need to understand what is more important then other
09:30:47 <gsagie> for DPDK you need something else
09:30:55 <Duan> has someone thought about live migration?
09:31:27 <gsagie> Duan: we need to do a talk about the requierments first and understand what is actually needed
09:31:45 <gsagie> i would like to understand how its done in Neutron DVR
09:31:48 <gsagie> (if it is)
09:32:10 <gsagie> anyway i think we will need to do a different meeting about that
09:32:16 <gampel> I think the main issue is having the port bound to two chassis for the post copy
09:32:40 <gsagie> Duan: maybe you, Omer and nick-ma can talk about things in OpenStack day China
09:32:56 <gsagie> and the rest of the team of course..
09:32:58 <nick-ma> sure. Omer and I have submitted a talk.
09:33:04 <nick-ma> it is done.
09:33:18 <Duan> nick, do you get some feedback
09:33:31 <nick-ma> feedback from where?
09:33:37 <Duan> aobut the talk submitted.
09:33:52 <gsagie> Duan: i think they already published the schedule
09:33:59 <gsagie> look at openstackdaychina.com
09:34:06 <nick-ma> Duan the application is done. i'm keeping in touch with the organizer.
09:34:24 <nick-ma> Duan we are discussing with the topic and content.
09:34:44 <Duan> OK
09:35:18 <gsagie> I will not be there unfortunately :(
09:35:34 <nick-ma> the topic has not been published to public yet. but it is there, the organizer confirmed.
09:35:35 <gsagie> But i think you will recover from that
09:36:10 <gsagie> gampel: please take over the chat for 2 mins i have to go
09:36:17 <gsagie> WC
09:37:04 <gampel> Ok whats the next topic
09:37:35 <gampel> I guess open discussions
09:38:01 <nick-ma> do we need to add features for core plugin, or we add them directly to ml2? like these ml2 extensions, qos, dns, etc?
09:38:52 <gampel> I think that after we merge the ML2 we should  support the new features in ML2 only
09:38:59 <gsagie> agreed
09:39:15 <oshidoshi> +1
09:39:16 <nick-ma> got it.
09:39:22 <gsagie> #topic open discussion
09:39:28 <gsagie> ok the bot is not working :(
09:39:43 <hujie> where should we put the db consistency logical? the ML2 driver or another process which is separate from neutron process
09:39:46 <nick-ma> it seems that ci is not working either. I cannot read the log.
09:39:47 <oshidoshi> oh.. the bot had to leave, said you should take over
09:40:10 <gsagie> How can we work in such conditions :)
09:40:24 <gsagie> carl_baldwin: ??? :)
09:40:28 <oshidoshi> hujie: i think a separate agent/daemon process
09:41:20 <nick-ma> hujie: do you have code available?
09:41:59 <hujie> basically, but I need to confirm the place to deploy the code
09:42:20 <gsagie> yuval: you have to admit that this talk is more fun then Smaug
09:42:33 <gsagie> you need to join and send some patches in Dragonflow yuval
09:42:48 <yuval> gsagie: feel free to suggest some :)
09:43:09 <nick-ma> hujie: i think a separate daemon
09:43:23 <hujie> like the publish service?
09:43:27 <nick-ma> yes
09:43:29 <hujie> in Neutron plugin side
09:43:32 <hujie> ok
09:43:38 <gsagie> hujie: i think you have a way to register "workers"
09:43:48 <gsagie> i know its possible with the plugin, not sure about the ML2
09:44:15 <gsagie> but i will check for you
09:44:27 <hujie> ok thank you :)
09:44:36 <Duan> like rpc/api workers?
09:44:42 <gsagie> Duan: yep
09:44:50 <gsagie> exacly, but you can have your own implementation
09:44:53 <yamamot__> gsagie: odl ml2 driver has worker threads and has (had?) startup issues
09:45:10 <gsagie> yamamot__: ohh thanks for the tip, you remember why>
09:45:11 <gsagie> ?
09:45:26 <gsagie> i think there was some work to fix it recently by Terry
09:45:28 <oshidoshi> I would avoid adding workers in the ml2 - it's an awkward design, imo
09:45:49 <yamamot__> i forgot details.  i don't know if it has been solved or not.
09:46:14 <gsagie> oshidoshi: the workers are there, its just a "platform" for running code..instead of adding another service
09:46:24 <gsagie> and Neutron suppose to know how to scale it :)
09:46:25 <Duan> oshidoshi, do you have some details about that problem?
09:46:55 <oshidoshi> gsagie: not saying workers are not technically there, just saying database reconciliation/consistency seems a bit awkward to put in ml2
09:47:16 <gsagie> oshidoshi: its in Neutron server not ml2
09:47:18 <oshidoshi> Duan: it's more of an architectural point of view.  technically, it can be done, but I don't think it belongs there
09:47:46 <gsagie> We need to see the design/code, i think it has to be there
09:47:51 <nick-ma> oshidoshi: do you suggest to make it as a new service?
09:47:53 <gsagie> because you need to stop adding entries
09:48:06 <oshidoshi> gsagie: yes, but the DB consistency check is not really related to Neutron... it's an imlementation-related ancilliary process, so i would leave it out and handle it separately
09:48:07 <gsagie> you dont want a "sync process" when user update API
09:48:35 <gsagie> so we will need a way to somehow sync between them
09:48:54 <oshidoshi> nick-ma: I don't know if it's a new service... don't really see the new service APIs...
09:49:21 <nick-ma> i just mean a separate process.
09:49:28 <gsagie> hujie: can you describe what the code is doing? for example will your process breaks if during the sync process a user change something in the API
09:49:48 <oshidoshi> usually, in big systems, when there are multiple databases holding partial views of the same data, there's a background reconciliation process that fixes discrepencies
09:49:49 <gsagie> you are comparing versions?
09:49:50 <nick-ma> i think it can be handled by distributed lock.
09:50:12 <hujie> gsagie: yes, just comparison
09:50:26 <gsagie> hujie: and if you find they are not synced, what do you do?
09:51:21 <hujie> for the recover msg, I'll do db comparison and sync the data
09:51:53 <Duan> gal, remove/insert some records to df db
09:52:10 <hujie> for the periodically process, I'll sync the data after db comparison twice verification
09:52:41 <gsagie> ok, we can do this in a seperate service for now
09:52:49 <hujie> you can review this spec: https://review.openstack.org/#/c/300877/
09:52:50 <gsagie> but need to see the code to understand that we are doing it right
09:52:55 <gsagie> hujie: ok thanks
09:54:15 <gampel> Yes lets all go over the code juts to make sure we are talking about the periodically check   only
09:55:11 <gsagie> ok, thanks everyone for joining
09:55:12 <hujie> ok let's go on:)
09:55:13 <oshidoshi> perhaps there's a way to make sure we have transactional consistency between neutron DB and DF DB without using additional workers/processes..
09:55:45 <yamamot__> oshidoshi: given the way neutron db is currently updated, the reconciliation process need to be somehow tightly coupled with the neutron server i guess.
09:56:20 <oshidoshi> yamamoto: we'll see :)
09:56:31 <gsagie> Let the Dragon flow!
09:56:37 <gsagie> and see you all next week
09:56:38 <yuli_s> ;)
09:56:48 <hujie> :)
09:56:49 <gsagie> yuli_s...
09:56:51 <oshidoshi> bye
09:56:58 <gsagie> #endmeeting