09:00:30 <oanson> #startmeeting Dragonflow
09:00:31 <openstack> Meeting started Mon Nov 21 09:00:30 2016 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:34 <openstack> The meeting name has been set to 'dragonflow'
09:00:36 <yuval> hey
09:00:38 <nick-ma_> hey
09:00:46 <dimak> hello
09:00:48 <oanson> Hello. Who's here for the Dragonlfow meeting?
09:01:03 <lihi> Hi
09:01:14 <xiaohhui> hi
09:01:35 <yuanwei> hello
09:01:52 <oanson> All right. Let's get started then
09:01:59 <oanson> #topic Ocata Roadmap
09:02:19 <oanson> The IPv6 spec has been merged
09:02:52 <oanson> That's great news :). The hard part is over.
09:03:19 <oanson> I see that the SFC spec is converging
09:03:32 <oanson> However, I suspect it might be too big for a single-cycle task
09:03:44 <oanson> dimak, would you like to say something?
09:03:46 <dimak> I'm waiting for more reviews
09:04:21 <dimak> I've revised it a bit yesterday to take into account metadata passing other than that I think it quite ready
09:04:37 <dimak> I'd love to see some more input
09:04:41 <oanson> That's great. I didn't have time to go over it yet.
09:05:05 <oanson> My question is, do you think it's something that can be done in Ocata?
09:05:32 <oanson> Or do you think it's a double-cycle project?
09:05:38 <dimak> As a standalone feature I think it might be possible
09:05:54 <oanson> All right. So let's time it for Ocata for now.
09:05:58 <oanson> Please update me if that changes.
09:05:59 <dimak> but it depends heavily on how fast can we push nsh to ovs
09:06:11 <dimak> at least in a side-branch
09:06:17 <oanson> I will also see if I can get you some help.
09:06:22 <dimak> thanks
09:06:31 <oanson> dimak, this we can do ourselves, and maintain the side branch ourselves (for now)
09:06:42 <oanson> If we take something based 2.6.1 it *might* be good enough.
09:06:49 <oanson> Although pushing it to upstream would be best
09:06:56 <nick-ma_> yes, just modify devstack to install ovs from source.
09:07:06 <oanson> Have you managed to rebase the patches?
09:07:18 <dimak> I didn't get to it yet
09:07:30 <oanson> No worries. This can be done in parallel.
09:07:53 <oanson> Anything else for SFC?
09:08:01 <dimak> I don't think so
09:08:37 <oanson> All right, the let's move on to chassis status/liveness/health
09:09:11 <oanson> xiaohhui, I see you updated the patch not long ago.
09:09:11 <xiaohhui> I have uploaded a new version of spec today
09:09:23 <xiaohhui> yes
09:09:57 <oanson> I didn't have a chance to look at it yet.
09:10:18 <oanson> But I think it was very close to being ready, so I'm hopeful :)
09:10:19 <xiaohhui> I address the comments, I think it is ready, but comments are always welcomed
09:10:32 <xiaohhui> Thanks :)\
09:10:40 <oanson> I hope that at this point there are only small things left.
09:11:24 <xiaohhui> I hope that too :)
09:11:29 <oanson> Anything else for chassis health/status/liveness?
09:11:38 <xiaohhui> Nothing from me
09:11:54 <oanson> Tap-as-a-Service
09:12:20 <oanson> After discussion with yamamoto, we agreed that there'll be a 'position' parameter added that will allow us to decide where to put the tap
09:12:41 <oanson> yuli_s, I see you updated the spec. I didn't have a chance to go over it. Did you add that part in?
09:13:18 <yuli_s> yes, I added it
09:13:32 <oanson> Great.
09:13:40 <yuli_s> please have a look
09:13:44 <oanson> Will do
09:13:56 <yuli_s> finally I resolved the problem I had in multi-node environment
09:14:10 <oanson> We will have to work with the TaaS team to see when it is added there. We may need to help.
09:14:11 <yuli_s> so, I will continue working on second part of the spec
09:14:17 <oanson> yuli_s, That's great.
09:14:28 <yuli_s> https://review.openstack.org/#/c/400102/
09:14:49 <oanson> I think the best plan right now is to support one value of 'position', and support the rest immediately after.
09:15:03 <oanson> This separation will allow us to do a cut-off when Ocata ends, if we need to
09:15:03 <yuli_s> yes
09:15:12 <yuli_s> suer
09:15:14 <yuli_s> sure
09:15:25 <oanson> Thanks
09:15:37 <oanson> Anything else for TAPaaS?
09:15:49 <yuli_s> currently no
09:16:09 <oanson> All right.
09:16:23 <oanson> The Anonymous sNAT person isn't here. I forgot to ask him to join.
09:16:50 <oanson> I would like to clarify the app-separation issue, since I am not sure I was clear
09:17:26 <oanson> My vision states that there are several sNAT apps.
09:17:36 <oanson> Only one runs in a node/Dragonflow configuration.
09:17:57 <oanson> The operator decides how sNAT behaves, and selects the Dragonflow sNAT app that has this behaviour.
09:18:29 <nick-ma_> does the spec include all these apps? i doubt.
09:18:38 <oanson> This way, the anonymous sNAT does not need additional configuration: If it is running, it is expected to do its "thing". Otherwise, a different app should be configured to run.
09:18:38 <xiaohhui> several snat app, you mean, distributed/centralized snat app, right?
09:19:02 <oanson> nick-ma_, I think that's out-of-scope for the spec. The spec is only for one snat implementation
09:19:04 <oanson> xiaohhui, yes.
09:19:20 <oanson> In general, is this vision acceptable?
09:19:34 <nick-ma_> ok.
09:19:40 <nick-ma_> of course.
09:19:44 <oanson> If so, I can add documentation explaining it.
09:19:46 <xiaohhui> is there plan to create centrialized snat and eliminate l3-agent?
09:20:02 <xiaohhui> centralized snat app
09:20:11 <oanson> xiaohhui, not to my knowledge.
09:20:31 <oanson> I think the quickest simplest way to build a centralised snat app is have it use the l3-agent. That means keeping the l3-agent
09:20:56 <xiaohhui> ok, so why will explicit centralized snat app needed? It could work with the l3 app now with l3-agent.
09:20:58 <oanson> Maybe once SFC is in, we can have a SF for sNAT, which will be centralised and work out-of-the-box.
09:21:50 <oanson> xiaohhui, The l3 agent should run only if the centralised snat app is configured. (This is not how it works now, but I think that should be changed. I'll see if I can get around to it)
09:22:11 <xiaohhui> I see..
09:22:17 <oanson> If there is no snat app, snat functionality should not work (including not having an l3-agent)
09:22:48 <oanson> I think the work on chassis liveness should help here - we discussed moving l3-agent to run using a ProcessManager from the controller.
09:22:49 <xiaohhui> With the df-controller manage the l3-agent in centralized snat app, right?
09:22:58 <oanson> xiaohhui, yes. Exactly
09:23:16 <xiaohhui> Thanks, I get it...
09:23:31 <oanson> Anything else for sNAT?
09:23:44 <irenab> oanson, can you please send the link to the spec?
09:23:49 <oanson> Sure.
09:24:00 <oanson> #link Distributed SNAT spec https://review.openstack.org/#/c/397992/
09:24:04 <irenab> thanks
09:24:16 <oanson> LBaaS
09:24:49 <oanson> I didn't have a chance to go over the comments on this one.
09:24:57 <oanson> Is there anything there that's a blocker?
09:25:29 <oanson> (Obviously, I expect the comments to be treated. The question is is the something that we need to discuss here?)
09:26:26 <oanson> Great. Then I guess the rest can be done on the spec.
09:26:50 <oanson> Anything else for roadmap?
09:27:06 <irenab> oanson, link to the LBaaS spec?
09:27:15 <oanson> Of course :)
09:27:26 <oanson> #link Load Balancer as a Server V2 specification https://review.openstack.org/#/c/397992/u
09:27:41 <oanson> I'll add the links to the meeting schedule too: https://wiki.openstack.org/wiki/Meetings/Dragonflow
09:28:05 <nick-ma_> the spec is not completed about the functionality, health monitor, control plane.
09:28:21 <irenab> oanson, its the sNAT one
09:28:28 <nick-ma_> i give my comments inline.
09:28:47 <oanson> #link Load Balancer as a Server V2 specification https://review.openstack.org/397997
09:29:27 <oanson> nick-ma_, yes. I saw you added this to the comments.
09:29:31 <xiaohhui> I remember I gave some comments too. But I don't remember exactly now, I guess we can carry on discussion in the spec
09:29:39 <oanson> denghui, will you be able to fill in the missing bits?
09:30:26 <denghui> sure, will be updated it soon.
09:30:33 <oanson> Great. Thanks!
09:30:45 <oanson> Anything else for roadmap?
09:31:20 <oanson> Great!
09:31:23 <oanson> #topic Bugs
09:31:37 <oanson> There are a couple of new bugs.
09:31:50 <oanson> There are two that I'm marking high:
09:31:58 <oanson> Bug 1642895
09:31:58 <openstack> bug 1642895 in DragonFlow "In large scale, SGApp will slow down the speed of processing a logical port updated event" [High,New] https://launchpad.net/bugs/1642895
09:32:09 <oanson> yuli_s, as part of your performance work, will you be able to look at it?
09:32:26 <yuli_s> i will take a look
09:32:46 <oanson> Thanks
09:32:56 <oanson> Bug 1642525
09:32:57 <openstack> bug 1642525 in DragonFlow "redis driver raise exception when node removed" [High,New] https://launchpad.net/bugs/1642525
09:33:19 <oanson> I will try and contact the guy who wrote the redis driver, see if he's willing to review the bug and send a fix
09:34:30 <oanson> The bug list is growing, but I think that's all right for now. I want to concentrate in the next month on new features
09:34:38 <oanson> (IPv6, NAT, LBaaS, SFC)
09:34:47 <oanson> And treat bugs in the month after that.
09:35:17 <nick-ma_> that makes sense.
09:35:29 <oanson> Obviously, if you upload a fix to a bug, it will be reviewed and merged. But I will give a greater stress on bugs later in the cycle.
09:35:47 <oanson> Anything else for bugs?
09:36:23 <oanson> #topic Open Discussion
09:36:30 <oanson> The floor is for the taking.
09:36:55 <yuli_s> i saw a number of bugs related to selective distribution
09:37:15 <yuli_s> that should be addressed asap
09:37:36 <oanson> yuli_s, in that case, please upgrade them to Critical, so we'll see them
09:37:44 <yuli_s> ok, great
09:37:53 <oanson> Do they all have owners?
09:38:02 <oanson> Anything specific you want to raise here?
09:38:16 <yuli_s> sec. will give numbers
09:39:05 <yuli_s> https://bugs.launchpad.net/dragonflow/+bug/1641626
09:39:05 <openstack> Launchpad bug 1641626 in DragonFlow "Failed to load VM in multi-node setup" [Critical,New]
09:39:18 <yuli_s> ops,
09:39:21 <yuli_s> it is wrong
09:39:57 <yuli_s> https://bugs.launchpad.net/dragonflow/+bug/1641903
09:39:57 <openstack> Launchpad bug 1641903 in DragonFlow "Exception in removing router in multi-node setup" [High,New]
09:40:03 <yuli_s> will make it critical now
09:40:32 <xiaohhui> I want to bring this review out. It has a +2 from nick-ma_  The refactor will be hard to rebase, so I hope it will not wait too long. https://review.openstack.org/#/c/393974/
09:41:30 <oanson> xiaohhui, I will look at it
09:41:38 <yuli_s> the CN had unsubscribed from topic before removing logical port
09:41:46 <yuli_s> and as a result , exception
09:42:42 <oanson> I don't think we have enough hands to take it right now.
09:42:47 <oanson> Unless someone volunteers?
09:42:47 <yuli_s> so, it is only 1 critical bug for now
09:43:07 <oanson> I'll take it. But it will take me a few days to reach it.
09:43:09 <xiaohhui> I can take it
09:43:17 <oanson> xiaohhui, even better :)
09:43:35 <oanson> It's yours. Thanks!
09:43:38 <xiaohhui> :)
09:44:00 <oanson> The floor is for the taking again.
09:44:55 <oanson> In that case, we can go to lunch/dinner early :)
09:45:00 <nick-ma_> :-)
09:45:02 <yuli_s> ;)
09:45:07 <xiaohhui> bye~
09:45:13 <oanson> Thanks everyone for coming, and for your efforts!
09:45:23 <oanson> #endmeeting