09:00:06 <oanson> #startmeeting Dragonflow
09:00:07 <openstack> Meeting started Mon Jan 23 09:00:06 2017 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:10 <openstack> The meeting name has been set to 'dragonflow'
09:00:24 <xiaohhui> hello
09:00:25 <dimak> Hey
09:00:28 <lihi> Hi
09:00:41 <oanson> Hi
09:00:47 <oanson> #info xiaohhui dimak lihi in meeting
09:01:27 <oanson> Let's wait another minute.
09:01:33 <nick-ma_> hi
09:01:37 <oanson> I'll update the schedule in the meantime :)
09:02:15 <oanson> #info nick-ma rajivk also in meeting
09:02:25 <oanson> All right. Let's begin!
09:02:27 <oanson> #topic Roadmap
09:02:33 <oanson> IPv6 - lihi, take it away
09:03:15 <lihi> I have made some progress, I home to upload a patch in the next days (router advertisement)
09:03:28 <lihi> I've managed to send the router advertisement as response. I just want to make sure that I'm advertising all the possible messages.
09:03:55 <oanson> Once that happens, that means that IPv6 enabled VMs will work?
09:03:57 <oanson> With SLAAC?
09:05:09 <oanson> And this means that DHCPv6 and Security Groups are left, right?
09:05:17 <lihi> I think it should work already :)
09:05:20 <lihi> Yes
09:05:46 <lihi> and another small section of the ND
09:06:06 <oanson> That's great. It would be great if you could also write up how you test it - what VM images you use, and how you set them up (cloud-init script, etc.)
09:06:06 <lihi> But I think it is less important than DHCPv6 (Redirect)
09:07:11 <oanson> Great. Thanks! Anything else?
09:07:25 <lihi> OK, sure
09:07:47 <lihi> nope
09:07:49 <oanson> As far as I know, there was no progress in SFC
09:08:08 <dimak> I actually rebased my work on the refactoring patches
09:08:20 <dimak> and managed to throw away a lot of the gluework patches
09:08:28 <oanson> dimak, that's good.
09:08:35 <oanson> Less to review :)
09:08:46 <dimak> 😛
09:08:57 <oanson> service health. There's the patch https://review.openstack.org/#/c/415997/
09:09:23 <oanson> From the looks of it, there are only cosmetic changes. Nothing major.
09:09:28 <oanson> rajivk, anything to report?
09:09:28 <rajivk> I am not able to work on it. I will submit patch soon.
09:09:41 <rajivk> May be tomorrow.
09:09:48 <oanson> Great. Thanks!
09:10:18 <oanson> TAPaaS - yuli_s are you here?
09:10:26 <ishafran> Hi
09:10:44 <itamaro> Hi
09:10:46 <oanson> All right. I'll try and catch him offline.
09:10:53 <oanson> ishafran, itamaro hi
09:11:02 <oanson> #info ishafran itamaro are also in meeting
09:11:14 <oanson> ishafran, right on time! It's Anonymous sNAT time!
09:11:19 <oanson> I saw there's a new patch
09:11:24 <ishafran> :)
09:11:37 <ishafran> I pushed new review request for code
09:11:43 <ishafran> https://review.openstack.org/#/c/417799/2
09:12:11 <oanson> Great. Thanks.
09:12:29 <ishafran> going to start second implementation  alternative
09:12:31 <oanson> Everyone, please review the spec: https://review.openstack.org/#/c/397992/ so we can move forwards on this
09:13:01 <oanson> ishafran, you mean the one marked 'Model alternative [2]' in the spec?
09:13:11 <ishafran> yes
09:13:18 <oanson> Great!
09:13:59 <oanson> anything else for sNAT?
09:14:18 <ishafran> no
09:14:27 <oanson> NB Refactor and API.
09:14:45 <oanson> dimak uploaded many patches. dimak, are they ready for review?
09:15:10 <dimak> I hope they will be soon
09:15:23 <dimak> Jenkins is happy with almost all of them :)
09:15:47 <oanson> All right. You mentioned you're going to unify some of them, like the namespace patch. Is that still planned?
09:16:12 <dimak> I wanted to discuss new models and their impact on df_publisher_service but I can bring it up in the open discussion
09:16:22 <oanson> I think that would be best
09:16:29 <oanson> irenab, are you in?
09:16:49 <dimak> I don't plan on unifying at the moment
09:17:10 <oanson> dimak, great. Thanks!
09:17:27 <dimak> and I'll drop namespace patch if xiaohhui will insist on it. I've updated it to address concerns raised
09:17:52 <xiaohhui> will check it.
09:17:58 <dimak> thanks :)
09:17:58 <oanson> irenab isn't here. The is a spec is in WF-1, but I Think it's fairly advanced. I guess she'll update during the week.
09:18:21 <oanson> Anything else for roadmap?
09:18:58 <oanson> #topic bugs
09:19:38 <oanson> There are many 'High' priority bugs.
09:19:56 <oanson> Those around sNAT/dNAT will be solved with dimak's and ishafran's work
09:20:03 <oanson> (I'll close the one on me)
09:20:32 <oanson> Bug 1655935 will be solved by the NB refactor
09:20:32 <openstack> bug 1655935 in DragonFlow "df-controller does not create tunnel to newer controllers" [High,New] https://launchpad.net/bugs/1655935
09:20:32 <dimak> My chassis / tunnels bug needs update
09:20:40 <dimak> This one
09:20:59 <dimak> its probably due to df_publisher being down due to bind error
09:21:02 <dimak> (address in use?)
09:21:17 <dimak> which happens all the time in devstack with zmq
09:21:19 <oanson> Yes. That looks like bug 1651643
09:21:19 <openstack> bug 1651643 in DragonFlow "metadata service cannot start due to zmq binding conflict" [High,In progress] https://launchpad.net/bugs/1651643 - Assigned to Li Ma (nick-ma-z)
09:21:45 <xiaohhui> we are actually using virtual tunnel port now, so there will be no tunnel between every 2 controllers
09:22:28 <oanson> Yes
09:22:56 <oanson> dimak, I'm putting 1655935 on you. Either way, your work (or xiaohhui 's previous patches) should solve the issue
09:23:14 <dimak> Ok
09:23:16 <oanson> nick-ma_, are you managing with bug 1651643, or do you want help?
09:23:16 <openstack> bug 1651643 in DragonFlow "metadata service cannot start due to zmq binding conflict" [High,In progress] https://launchpad.net/bugs/1651643 - Assigned to Li Ma (nick-ma-z)
09:23:37 <nick-ma_> the design of zmq driver implies that only neutron server starts publisher, but some applications break it. so, we need to rethink the pubsub implementation.
09:24:00 <nick-ma_> the metadata service is running now.
09:24:13 <oanson> That's good.
09:24:32 <oanson> Do you have a list of which apps break the assumption?
09:25:57 <oanson> I think maybe all in-code pub/sub (in zmq) should use the multiproc pub/sub. Only the df_publisher service should use the tcp port-binding publisher
09:26:20 <oanson> We'll make sure in deployment (devstack, etc.) that the publisher service is up if it's needed.
09:26:30 <oanson> nick-ma_, does that make sense? Or am I missing something completely?
09:28:54 <oanson> All right, I'll add that question to the bug, and we'll continue there
09:29:02 <oanson> Anything else for bugs?
09:29:52 <oanson> #topic Open Discussion
09:30:06 <oanson> The floor is for the taking.
09:30:15 <nick-ma> my network seems not good
09:30:22 <oanson> nick-ma, in case you missed it, I said we'll continue the discussion on the bug page
09:30:29 <nick-ma> OK
09:30:30 <oanson> (It's a little slower, but more stable (: )
09:30:43 <dimak> I wanted to bring up the publisher thing I mentioned earlier
09:31:20 <oanson> Sure. Go ahead
09:31:22 <nick-ma> sure.
09:31:42 <dimak> It seems that for some models we notify events from NbApi but for others from publisher service
09:32:11 <oanson> You mean the use of table monitors, and the such?
09:32:19 <dimak> And it makes sense because that way we can filter updates of fields deemed irrelevant to all nodes (e.g. timestamps)
09:32:23 <dimak> Yeah
09:33:27 <oanson> dimak, yes?
09:33:33 <dimak> It creates a centralized POF
09:33:53 <dimak> and several neutron servers will notify the same events right?
09:34:02 <nick-ma> spof?
09:34:07 <dimak> yes
09:34:10 <dimak> sorry
09:34:18 <oanson> Yes. Looks like it.
09:34:36 <oanson> POF - Point of Failure, right?
09:34:38 <dimak> yes
09:34:57 <nick-ma> yes, i'm also thinking of that when i was trying to fix the bug.
09:35:21 <dimak> I think that instead of bouncing the updates through publisher
09:35:27 <oanson> This was our way to avoid controller-side publishers. Since chassis are updated by controllers.
09:35:31 <dimak> we can decide locally whether we notify or not
09:36:30 <dimak> we can define some fields as 'volatile' on new models, then if an update is only on these fields, no use to send event
09:36:50 <dimak> but over all, all models behave the same
09:37:03 <oanson> dimak, this sort of change will have to wait until after we solve the bug
09:37:14 <oanson> Since this sort of behaviour is causing us issues already
09:37:23 <dimak> and updates will be sent regardless of publisher service is up or not
09:38:14 <oanson> That makes sense - if a chassis can't send the update - it is not really up. Same for a publisher.
09:39:04 <dimak> we can keep monitoring stale entries in publisher service and issue state changes to down if needed
09:40:27 <nick-ma> what do you mean about the state?
09:40:43 <dimak> like marking chassis as 'down'
09:40:53 <oanson> Then we can decide if this monitoring is done in the publisher service or the controllers themselves - since it will be done rarely (once a minute, or so)
09:40:54 <dimak> and notifying all other nodes
09:41:30 <oanson> I think this is a good direction. But I want to wait with it until after the bug is solved.
09:41:37 <dimak> sure
09:41:46 <oanson> Thanks for bringing this up.
09:41:49 <nick-ma> yes, we can discuss with it later.
09:42:06 <oanson> The floor is free again.
09:43:41 <oanson> All right. I think we can head for lunch/dinner early.
09:43:49 <oanson> Thanks everyone for the great work. Keep it up!
09:43:55 <nick-ma> thanks.
09:44:06 <oanson> #endmeeting