08:01:26 <oanson_> #startmeeting Dragonflow
08:01:27 <openstack> Meeting started Mon Nov 13 08:01:26 2017 UTC and is due to finish in 60 minutes.  The chair is oanson_. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:01:28 <dimak> hey
08:01:30 <openstack> The meeting name has been set to 'dragonflow'
08:01:32 <oanson_> Hi
08:01:34 <snapiri> Hi
08:01:36 <oanson_> Who's here for the weekly?
08:01:37 <irenab> hi
08:01:44 <lihi> Hi
08:01:53 <leyal> hi
08:02:12 <oanson_> Give me a minute to find the agenda, and we can start
08:03:30 <oanson_> All right. Let's start
08:03:33 <oanson_> #topic Roadmap
08:03:49 <oanson_> First off, let me say that lihi and I were in the Sydney summit.
08:03:53 <oanson_> It was lotsa fun
08:03:57 <oanson_> But it's nice to be home
08:04:10 <irenab> sorry having meetings conflict, will catch up later
08:04:21 <oanson_> We had some interesting talks, which may change a bit the strategy. We'll see how it affects this meeting and next (The ship is still rocking)
08:04:25 <oanson_> LBaaS
08:04:46 <oanson_> Please throw your comments at the spec (link in a second)
08:04:51 <oanson_> #link LBaaS spec https://review.openstack.org/#/c/477463
08:04:58 <oanson_> This way we can start the implementation
08:05:11 <oanson_> DNS
08:05:21 <oanson_> We spoke with the Designate PTL. He's very nice.
08:05:47 <oanson_> Mostly he said that Designate sits on top of the Neutron DNS integration extension. So our DNS application should only concentrate on that.
08:06:05 <dimak> oanson_, what do you mean?
08:06:08 <oanson_> The good news is that it's a very simple API, so the application (barring the general difficulties in DNS) shouldn'
08:06:14 <oanson_> shouldn't be too complex
08:06:47 <oanson_> dimak, Neutron gives a DNS server (via dnsmasq, IIRC), and then provides the 'next hop DNS' (I forgot the terminology)
08:07:10 <dimak> Who deploys the actual DNS service?
08:07:13 <dimak> Designate?
08:07:57 <oanson_> Neutron deploys dnsmasq daemons. We're going to deploy our own. My guess is (lihi do you remember?) that designate integrates with a deployed DNS server (e.g. bind9) and populates it according to its API
08:08:33 <oanson_> I think the DNS server has to be deployed manually (but maybe deployment options like devstack and OSA provide help with that)
08:08:49 <lihi> Yes I think they deploy their own DNS server
08:09:01 <oanson_> In any case, it's beyond the scope of the Dragonflow application. So that's good news for us.
08:09:04 <dimak> So if that DNS server has a port, what's there for Dragonflow?
08:09:39 <oanson_> We need to provide a DNS server (-like behaviour) that answers DNS requests for Neutron ports
08:09:49 <oanson_> As per the Neutron DNS integration extension.
08:10:00 <oanson_> lihi, I don't have access to it now - could you post the links to the docs?
08:10:26 <dimak> You plan on answering it from the controller?
08:10:29 <lihi> https://docs.openstack.org/mitaka/networking-guide/config-dns-int.html
08:11:08 <oanson_> dimak, two options: 1. yes. 2. Have a DNS server that answers the request in a similar fashion to the metadata service or HA proxy design in LBaaS.
08:11:36 <dimak> I may be missing something but I don't see the benefit
08:11:50 <oanson_> dimak, I don't think the integration is supported at the moment
08:12:04 <oanson_> We don't have those dnsmasq daemons running in current DF deployment
08:12:13 <dimak> If that's just a port like lbaasv2 then there's no problem
08:12:20 <oanson_> No one to answer DNS requests - it's just forwarded to the configured general DNS server
08:12:56 <dimak> We can use dhcp-agent
08:13:14 <oanson_> Both options require development: Option 1. requires writing the packet handler in the controller. Option 2. requires writing the server: Both reading the info and matching (mangled) IP addresses to ports
08:13:33 <oanson_> The second is needed to know to which project/network the port belongs
08:13:54 <dimak> unless designate deploys a DNS server like LBaaSv2 deploys a loadbalancer
08:14:01 <oanson_> We may be able to use an existing dhcp-agent with a few modifications, or an existing DNS library
08:14:22 <oanson_> dimak, I think whatever Designate deploys is centralised, so that's not a problem for us
08:15:00 <leyal> it's sound similar to dhcp , maybe we can prevent from the dns request to leave the compute-node ..
08:15:17 <oanson_> leyal, that's the plan for things we know to respond to
08:15:19 <dimak> Then you have to run bind9 on all nodes
08:15:31 <oanson_> Within limits of course - we don't want the compute node to work too hard
08:15:51 <oanson_> That's why I'm looking at something more lightweight than bind9, like dnsmasq or a simple python service
08:16:22 <oanson_> Do we all agree this is a feature we want?
08:16:34 <oanson_> i.e. to support Neutron DNS integration ?
08:16:36 <dimak> then you'll need one per "namespace"
08:16:54 <oanson_> dimak, I think we can avoid that using existing patterns
08:17:37 <dimak> It just seems a lot of effort and resources to distribute DNS
08:18:08 <dimak> A classic DC does not need one on every node
08:18:10 <oanson_> The Neutron integration allows you to look up VMs in your project using DNS. That's the part we want to distribute
08:18:19 <dimak> enough to have a few and do HA
08:18:36 <oanson_> We can use that solution, but then how do you encode who can see whom?
08:18:59 <dimak> if you're using bind9, it supports that
08:19:14 <oanson_> Let's split this discussion in two: 1. Do we want to support this extension? 2. How do we go about it?
08:19:15 <dimak> you can have a different view based on query origin
08:19:21 <dimak> Sure,
08:19:29 <oanson_> Let's vote on 1.:
08:19:30 <oanson_> +1
08:19:31 <dimak> +1
08:19:35 <lihi> +1
08:19:45 <oanson_> leyal, irenab, snapiri ?
08:20:00 <leyal> +1
08:20:22 <oanson_> All right, with +4 and 2 abstaining due to timeout, we can go forwards with this
08:20:28 <oanson_> lihi, you still want this feature?
08:20:41 <lihi> Yes, I can take it
08:21:07 <oanson_> All right. Then please fire up a spec including the three options (or less, if you think some aren't realistic), and we'll continue the rest of the discussion there?
08:21:13 <oanson_> dimak, good enough for you?
08:21:27 <dimak> sure
08:21:53 <lihi> 👍
08:22:00 <oanson_> Great. Then let's move on
08:22:43 <oanson_> L3 flavour -
08:23:04 <oanson_> I'm demoting this for now. It doesn't fit with our immediate strategy
08:23:11 <oanson_> ETCD publisher -
08:23:19 <oanson_> I believe this was merged?
08:23:47 <oanson_> lihi, ?
08:24:14 <lihi> oanson_, yes
08:24:19 <oanson_> Coo.l
08:24:24 <lihi> Before the summit
08:24:28 <oanson_> Cool!
08:24:36 <oanson_> Upgrades -
08:24:50 <oanson_> dimak, I believe we said we're giving this one some air in favour of the wiring feature?
08:25:10 <dimak> There's an issue I have there
08:25:19 <dimak> that we should see how we can resolve
08:25:28 <dimak> It's on the spec
08:25:34 <oanson_> dimak, all right. Then let's take it there
08:25:43 <oanson_> Wiring: The spec is here:
08:25:51 <oanson_> #link Wiring spec (Datapath abstraction) https://review.openstack.org/#/c/503538/
08:26:25 <oanson_> dimak, I think the current direction is a good one.
08:26:36 <dimak> Thanks
08:26:42 <oanson_> If we want to change the language later, we can always build a compiler to/from the new language
08:26:45 <dimak> Will try to drive it to completion
08:26:50 <oanson_> Thanks.
08:27:00 <oanson_> I think this is the last step to support pure out-of-tree applications
08:27:13 <oanson_> Unless there's something I forgot?
08:27:38 <oanson_> Yes there is: stevedore for models. But that's a small item
08:27:59 <oanson_> Anything else for features roadmap?
08:28:28 <oanson_> #topic Deployment
08:28:48 <oanson_> RPM packaging: I spoke with RDO guys at the summit. We agreed on what has to be done.
08:28:56 <oanson_> OSA - lihi ?
08:29:35 <lihi> Discussed with evrardjp, we've got action items to get this thing working
08:30:31 <oanson_> Sounds good!
08:30:44 <oanson_> incorporating DF into existing clouds
08:30:54 <oanson_> Does this belong to anyone?
08:31:27 <oanson_> That's a shame. Since we're all fully booked, it will have to wait. But it would be great to have this done by end-of-cycle
08:31:39 <oanson_> Anything else for deployment?
08:32:05 <oanson_> #topic Gates
08:32:20 <oanson_> Grenade depends on upgrade, so that will take a whil
08:32:24 <oanson_> while*
08:32:37 <oanson_> Tempest gate - snapiri did some good work there
08:32:59 <oanson_> In this patch: https://review.openstack.org/#/c/517814/
08:33:09 <snapiri> all exceptions cleared, take a few that will be handled by leyal's patch
08:33:17 <oanson_> All right. Cool
08:33:43 <oanson_> I see they conflict, but I understood that the conflicts aren't difficult. So we'll see which one lands first :)
08:33:55 <snapiri> :)
08:33:58 <oanson_> By the way, the other patch is: https://review.openstack.org/#/c/503965
08:34:13 <oanson_> cores, take your pick :)
08:34:55 <dimak> snapiri, any chance you can split that patch into separate changes?
08:35:05 <dimak> So we can examine each fix individually
08:35:17 <oanson_> ^^^ +1
08:36:07 <snapiri> I think so, though each change is quite self-contained in one file
08:36:30 <oanson_> It would still make the review process easier
08:36:42 <leyal> +1
08:36:46 <snapiri> can do
08:37:09 <oanson_> Kuryr integration gate: Discussed with apuimedo and dmellado during the summit. We're going to have both a single node and multi node tempest gates, which will run the same tests for ODL and DF, and maybe even DF specific tests in the future
08:37:38 <oanson_> (This is more of a status update. I don't think we have much to do here yet)
08:37:50 <oanson_> The gates will be different than the existing install gate
08:37:54 <oanson_> Anything else for gates?
08:38:34 <oanson_> #topic Troubleshooting
08:39:38 <dimak> oanson_, I've uploaded our skydive hackathon code
08:39:45 <oanson_> OSProfiler - I haven't seen any changes on the patch. snapiri - could you maybe put together a quick tutorial? We can then publish it as a docs or blog post
08:39:52 <oanson_> dimak, thanks!
08:40:04 <oanson_> dimak, linky?
08:40:14 <dimak> Sure, available here: https://review.openstack.org/#/c/518670/
08:40:17 <snapiri> oanson, let's take it offline
08:40:24 <oanson_> snapiri, sure. Thanks!
08:40:33 <dimak> It's very raw
08:40:53 <snapiri> dimak, you can say this again :)
08:40:56 <oanson_> All right. I think we'll work together to get it merge-ready
08:41:11 <dimak> It's good for playing around but I think we should write a spec and formalize what we want
08:41:17 <oanson_> We also have some design questions that need to be answered
08:41:28 <oanson_> dimak, great minds, etc... :)
08:41:45 <dimak> As in - where do we run it? An app? Service plugin? What resources? How?
08:41:52 <oanson_> Makes sense
08:42:14 <oanson_> It also looks like our 'topology viewer' will be integrated into Skydive as well.
08:42:33 <oanson_> snapiri, so maybe you can add your 2 cents to the design too?
08:43:11 <oanson_> snapiri, ?
08:43:14 <snapiri> did not get to it yet. we can have a discussion and try to formalize something concrete later this week
08:43:47 <oanson_> Sure. Let's take this offline then
08:43:48 <snapiri> though I had some thoughts I already shared with you
08:44:08 <oanson_> #topic Documentation
08:44:32 <oanson_> dimak, snapiri, lihi, you mentioned you have an etherpad with the new docs structure?
08:44:54 <oanson_> Could one of you share it, please?
08:44:58 <dimak> Yes, a moment
08:44:59 <lihi> # link https://etherpad.openstack.org/p/dragonflow-documentation
08:45:07 <lihi> #link https://etherpad.openstack.org/p/dragonflow-documentation * :)
08:45:42 <oanson_> All right. The next step is to start picking it apart and writing these things
08:46:13 <oanson_> When you have time, just mark a page as taken, and then take it and write it.
08:46:29 <oanson_> There is no real rush, but it would be great to have everything finished by end-of-cycle
08:46:31 <dimak> I think for starters we can restructure our ToC
08:46:46 <dimak> and move relevant things where they belong already
08:46:56 <oanson_> Sure. We can start with that
08:47:18 <oanson_> I think the brunt of the work will be the actual writing, rather than the restructuring, but it's a good place to start.
08:47:39 <oanson_> Anythign else for docs?
08:47:42 <oanson_> Anything*
08:48:20 <oanson_> #topic Bugs
08:48:42 <oanson_> We still have one critical bug: https://bugs.launchpad.net/dragonflow/+bug/1720734
08:48:42 <openstack> Launchpad bug 1720734 in DragonFlow "Floating IP association to LBaaS VIP supported by Octavia does not work" [Critical,New]
08:48:52 <oanson_> I am working on a temporary solution here:
08:49:02 <oanson_> https://review.openstack.org/#/c/516101/
08:49:14 <oanson_> And I hope to turn this into a Neutron API (one sec, I'll find the RFE)
08:50:08 <oanson_> Neutron RFE: https://bugs.launchpad.net/neutron/+bug/1730845
08:50:08 <openstack> Launchpad bug 1730845 in neutron "[RFE] support a port-behind-port API" [Undecided,New]
08:50:19 <oanson_> Anything else for bugs?
08:50:28 <oanson_> Any particular bugs anyone wants to discuss?
08:50:55 <oanson_> #topic Open Discussion
08:51:05 <oanson_> Floor is for the taking. Knock yourselves out
08:51:34 <oanson_> Last chance?
08:52:06 <oanson_> All right.
08:52:08 <oanson_> Thanks everyone!
08:52:17 <oanson_> #endmeeting