08:03:39 <oanson> #startmeeting Dragonflow 08:03:40 <openstack> Meeting started Mon Oct 2 08:03:39 2017 UTC and is due to finish in 60 minutes. The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:03:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:03:43 <openstack> The meeting name has been set to 'dragonflow' 08:04:03 <oanson> Hello. 08:04:05 <leyal> Hi 08:04:07 <Natanbro> Hi 08:04:09 <oanson> Who's here for the Dragonflow weekly? 08:04:24 <oanson> Let's wait a minute for everyone to join in. 08:04:41 <dimak> hey 08:04:42 <oanson> And also for me to update the agenda :) 08:05:00 <irenab> hi 08:05:58 <oanson> All right. 08:06:06 <oanson> #info leyal Natanbro dimak irenab in meeting 08:06:18 <oanson> lihi is on holiday, so she won't be joining us :( 08:06:25 <oanson> #topic Roadmap 08:06:51 <oanson> LBaaS: Nothing to update. Spec is still here: https://review.openstack.org/#/c/477463/ 08:06:58 <oanson> L3 Flavour 08:07:15 <snapiri> Here as well :) 08:07:22 <oanson> #info snapiri also in meeting 08:07:58 <oanson> I've talked to yamamoto regarding the L3 flavour. It looks like the plan is to allow an 'optimized' pipeline between l2 and l3, and a 'legacy' pipeline. Note: Looks like, as nothing was finalized. 08:08:16 <dimak> oanson, there's something in writing? 08:08:24 <oanson> There's an IRC log :) 08:08:24 <irenab> oanson, any refs? 08:08:56 <oanson> I can find the log. I can also try to talk to yamamoto and armax and publish a summary (if they haven't already) 08:09:13 <oanson> The optimized will allow e.g. Dragonflow to keep everything in the OVS switch. The legacy will allow everything to go via an intermediary port 08:09:45 <dimak> Ok, sounds reasonable. 08:09:54 <irenab> optimized == native? 08:09:57 <oanson> In general, once that's settled, the L3 flavour will be an l3 app, with classification/dispatch that reads packets of the ports. 08:09:59 <oanson> irenab, yes 08:10:32 <oanson> A method to identify whether we are using 'optimized' or 'legacy' configuration wasn't discussed in detail. 08:10:37 <irenab> I guess legacy is the integration with non-DF router 08:10:43 <oanson> For us, yes 08:11:07 <oanson> I don't think we can do optimized with OVS, OVN, etc., since we have different assumptions on the pipeline 08:11:12 <irenab> not sure I understand what does in mean on neutron side 08:11:21 <oanson> What do you mean? 08:12:02 <irenab> Did you discuss DF or neutron related stuff with yamamoto? 08:12:37 <oanson> We discussed the general L3 wiring. He bought examples from midokura, and I used DF as an example 08:13:08 <irenab> So my question was about the impact on neutron, if any 08:13:25 <irenab> I assumed optimized/legacy is in the neutron 08:14:05 <oanson> Yes 08:14:17 <oanson> ML2 drivers should support legacy as well as optimized. 08:14:23 <irenab> ok, lets see the summary 08:14:47 <irenab> shouldn't ml2 be sort of agnostic? 08:14:55 <oanson> That means we may also want a classifier/dispatch apps for L2 only, i.e. which output packets to a different L3 implementation 08:15:15 <oanson> That means we can't have an optimized pipeline. Not sure we want to give that up. 08:17:07 <oanson> Anything else for L3 flavour? 08:18:05 <oanson> I think we can skip ETCD and OSA, as the owner isn't here 08:18:14 <oanson> RPM packaging hasn't changed. 08:18:24 <oanson> I asked in the channel, and I'm trying to find a sponsor for my patch 08:18:46 <oanson> This is the patch link, https://bugzilla.redhat.com/show_bug.cgi?id=1494979 08:18:47 <openstack> bugzilla.redhat.com bug 1494979 in Package Review "Review Request: python-jsonmodels - Models to make easier to deal with structures that are converted to, or read from JSON in python" [Medium,New] - Assigned to nobody 08:19:22 <oanson> We need python-jsonmodels for Dragonflow. It is a must (unlike some of the driver requirements which can be done... differently....) 08:19:43 <oanson> Upgrade and Grenade: dimak, you want to take this? 08:20:06 <dimak> I've revised the upgrade spec yesterday 08:20:23 <dimak> And uploaded a newer version of the code that implements migrations 08:20:42 <dimak> Once the CI back to its senses I'll try to make sure it works with granade 08:21:07 <oanson> dimak, so you plan to add a grenade gate soon? 08:21:39 <dimak> yes 08:21:53 <dimak> we must make sure our migrations are sane 08:22:04 <oanson> Cool 08:22:20 <dimak> that's it for me 08:23:02 <oanson> Let's try and push this one as fast as possible. People, please review the spec. Database changes are blocked until this feature is progressed. 08:23:24 <irenab> I posted few comments yesterday 08:23:25 <dimak> +1 08:23:41 <oanson> Anything else for roadmap? 08:24:03 <leyal> i will be happy for comments for dhcp spec .. 08:24:07 <oanson> By the way, upgrade spec link: https://review.openstack.org/#/c/500647/ 08:24:19 <irenab> leyal, will review asap 08:24:21 <dimak> irenab, sorry I missed it, it was on an older revision 08:24:24 <leyal> https://review.openstack.org/498464 08:24:54 <leyal> irenab, 10x 08:25:23 <oanson> Anything else for roadmap? 08:26:17 <oanson> #topic Bugs 08:26:32 <oanson> Any bugs anyone wants to discuss? 08:26:36 <irenab> yes 08:26:47 <oanson> Shoot 08:26:56 <irenab> dimak and me revelaed some but related to FIP to VIP with Octavia 08:27:10 <irenab> https://bugs.launchpad.net/dragonflow/+bug/1720734 08:27:11 <openstack> Launchpad bug 1720734 in DragonFlow "Floating IP association to LBaaS VIP supported by Octavia does not work" [Undecided,New] 08:27:17 <dimak> yes, I'll post more info there 08:27:35 <dimak> but basically, fip breaks there because the fixed port is not bound 08:28:02 <dimak> the way it works, octavia listens with allowed address pair for VIP traffic 08:28:14 <dimak> VIP port itself stays unbound 08:28:28 <dimak> so FIP app is not aware of the port being online 08:28:43 <oanson> dimak, proposed solution? 08:28:59 <dimak> oanson, don't have anything concrete yet 08:29:21 <oanson> Do we have control over how octavia creates the vip port? 08:29:24 <dimak> we can add some app that handles octavia ports and teached dragonflow of the semantics 08:29:38 <dimak> teaches* 08:29:48 <oanson> That's a very octavia-specific solution. 08:29:50 <irenab> I would prefer not to have Octavia specific 08:29:51 <dimak> not at the moment 08:30:12 <irenab> maybe we should see the allowed-address pairs handling 08:30:17 <dimak> that's why I said I don't have anything yet :) 08:30:52 <irenab> We should check the support in vanila neutron 08:31:58 <irenab> anyway, this is blocking kuryr integration for external services once LBaaS is provided by Octavia 08:32:06 <irenab> it works with HA Proxy 08:32:22 <oanson> dimak, we had a distributed/virtual lport spec floating about. Do you remember the link? Or what happened with it? 08:32:32 <dimak> merged 08:33:07 <dimak> thing is, vips are not exactly distributed :( 08:33:38 <oanson> And we don't want floating IPs to think they are, because we want to bind to a specific compute node 08:35:48 <oanson> All right. Let's take this offline. 08:35:52 <oanson> Any other bugs? 08:36:20 <oanson> Marked as critical, since this blocks Kuryr+Octavia integration 08:36:53 <oanson> Last chance for bugs? 08:37:33 <oanson> #topic Open Discussion 08:37:41 <oanson> As you all noticed our gate is broken 08:37:51 <oanson> The upgrade to Zuulv3 went... less than swimmingly... 08:38:20 <oanson> leyal is working on it, and the guys at infra are also helping (us, and neutron-dynamic-routing) 08:39:00 <leyal> we have a patch - it's looks little bit better - but the tests still not reconize neutron :( 08:39:10 <oanson> Try looking at this patch https://review.openstack.org/508775 08:39:22 <oanson> bgp have the same issue. He tried renaming the test names. 08:39:35 <oanson> Note also the depends-on in that patch. It's needed if we're to try the same thing 08:40:32 <oanson> Anything else on this? 08:40:37 <leyal> sure , i will update in channel about the status .. 08:40:46 <oanson> Great. 08:40:55 <snapiri> If you need assistance let me know 08:41:05 <oanson> I think this should be top priority, since except specs, nothing can move forwards without a working gate. 08:41:48 <leyal> sure 08:42:00 <oanson> Next item. vPTG. 08:42:12 <dimak> technically, specs cant gate either :P 08:42:31 <oanson> dimak, yes. I definitely blocked a spec since it didn't pass fullstack :) 08:42:53 <oanson> I have sent an email setting the date to 18th-19th Oct. It's the best I could do. 08:43:15 <oanson> I am still not sure which video platform to use for video conference, but that's a technical issue. 08:43:43 <oanson> We still need to set the schedule. If no one does it, I'll do it at random at the 15th of October. So be aware :) 08:44:24 <oanson> Note also that I like getting up early, so things could start at 5AM UTC :) (But not likely) 08:44:51 <oanson> Anything else for vPTG? 08:45:58 <oanson> I think that's all I have 08:46:03 <oanson> The floor is free 08:46:09 <oanson> No wait 08:46:12 <oanson> I have one more: 08:46:20 <oanson> I am cancelling the next two meetings. 08:46:32 <oanson> Next week is a holiday, and probably no one will be here 08:46:48 <oanson> The week after most of the team is at a conference. 08:47:00 <oanson> I'll send out an email tomorrow 08:47:10 <oanson> Now the floor is free :) 08:48:03 <oanson> All right, then 08:48:08 <oanson> Thanks everyone for coming out! 08:48:13 <oanson> Thanks for the great work! 08:48:13 <dimak> bye 08:48:25 <oanson> #endmeeting