09:00:38 <oanson> #startmeeting Dragonflow
09:00:39 <openstack> Meeting started Mon Jun 12 09:00:38 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:40 <dimak> Hey
09:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:43 <openstack> The meeting name has been set to 'dragonflow'
09:00:49 <oanson> Hello. Who is here for the Dragonflow weekly?
09:01:18 <lihi> Hi all
09:02:09 <oanson> Let's wait another minute. Maybe nick-ma or xiaohhui will join
09:02:11 <oanson> Then we can start
09:03:31 <oanson> All right, then
09:03:59 <irenab> hi
09:04:06 <oanson> #info lihi dimak leyal irenab in meeting
09:04:12 <oanson> #info Roadmap
09:04:18 <oanson> #topic Roadmap
09:04:38 <oanson> Pike roadmap is coming along nicely.
09:05:00 <oanson> IPv6 is almost complete. lihi I see you uploaded the last patch?
09:05:40 <lihi> Yes, lets cross fingers that it will pass the gate :)
09:05:47 <oanson> Hear! Hear!
09:06:04 <oanson> Northbound API refactor is finally complete. Last patches were merged a few minutes ago
09:06:20 <oanson> Which broke the VLAN aware VMs patch - but I rebased it. It should be good to go.
09:06:25 <dimak> 🎊
09:06:49 <oanson> Lastly - SFC. dimak, any updates?
09:07:12 <dimak> I'm still working on getting it to play nice in multinode
09:07:22 <dimak> I'll rebase once it works
09:07:44 <oanson> Sure. You have an ETA?
09:08:11 <dimak> Around 2weeks-ish with all the ongoing stuff
09:08:23 <dimak> I'll need to make some changes to network access apps
09:08:28 <oanson> All right.
09:08:49 <oanson> I started working on LBaaS. I hope to have a spec up by the end of the week
09:09:25 <oanson> Anything else for roadmap?
09:10:37 <oanson> #topic Open Discussion
09:10:49 <oanson> Any open issues anyone wants to discuss?
09:11:15 <dimak> I took a look at the l3 flavor extension
09:11:18 <irenab> oanson, lbass driver for octavia?
09:11:30 <oanson> It will be part of the LBaaS spec
09:11:50 <oanson> The design will include L4,L7.
09:12:04 <oanson> Pools, monitors, classification, etc.
09:12:05 <dimak> Did you get to look at ovs+ebpf?
09:12:16 <oanson> It just takes time to sift through the docs
09:12:22 <irenab> its interal for DF, but from the OpenStack perspecive, it will be driver for Octavia, right?
09:12:30 <oanson> dimak, no. Do you have a link?
09:12:50 <oanson> Wait I have it
09:12:51 <oanson> http://openvswitch.org/support/ovscon2016/7/1120-tu.pdf
09:12:59 <dimak> Yes
09:13:10 <dimak> Plus there's bcc
09:13:20 <dimak> they have p4 to ebpf compiler
09:13:32 <oanson> Yes. That looks cool
09:13:33 <dimak> and some examples
09:13:45 <dimak> like the http monitor
09:14:02 <lihi> oanson it this supposed to be used instead or parallel to openflow?
09:14:49 <oanson> dimak, Did you look at ODL's southbound abstraction?
09:14:58 <dimak> I haven't
09:14:59 <oanson> lih, we haven't decided
09:15:20 <dimak> lihi, I read some slides that delegate some actions to ebpf programs
09:15:24 <oanson> In general, we're having issues deciding how all the applications play together when not tightly-coupled.
09:15:33 <dimak> and some slides that implement openflow in ebpf
09:15:54 <oanson> Having the apps implement themselves partly in OpenFlow, partly eBPF, partly P4, adds another layer of complexity.
09:15:54 <dimak> But I'm not sure any of this work was opensourced
09:16:12 <dimak> oanson, about the coupling
09:16:19 <oanson> Yes
09:16:21 <irenab> oanson, seems the issues of tightly coupled apps is not related to the southbound API
09:16:45 <dimak> as long as we have some notion of apps and their boundries, each app can implement itself as it sees best
09:16:56 <irenab> dimak, +1
09:17:14 <dimak> The datapath will just glue all the ports together
09:17:29 <oanson> irenab, true. I'm just saying that making the southbound API more flexible makes coupling/de-coupling the apps more complicated
09:17:35 <dimak> You can create a linux bridge + iptables and have taps for input output
09:17:40 <irenab> I am still concern if this way will lead to the optimised DP
09:17:42 <dimak> then ovs bridge with ports
09:17:45 <oanson> dimak, how will you define these boundaries?
09:17:47 <dimak> or ebpf
09:18:14 <dimak> by describing their method, be it taps, ovs table, veth pairs
09:18:56 <oanson> I'm not sure I want to throw in iptables, veth pairs, etc. to the mix
09:19:08 <irenab> sounds like there can be some meta language to define the app, and it can be 'compiled' to any SB API
09:19:26 <dimak> P4?
09:19:34 <oanson> irenab, yes, but it has to be defined.
09:19:40 <irenab> agree
09:19:41 <oanson> P4 is a good direction, I think
09:19:47 <dimak> But I was talking about something else
09:19:54 <irenab> need to consider the troubleshooting too, not to over complicate
09:19:57 <dimak> You can let each app have its own s/b
09:20:10 <dimak> and just connect the apps to create the pipeline
09:20:34 <oanson> irenab, yes. If we used a known language (e.g. p4) we can use/write general-purpose tools
09:20:57 <oanson> dimak, yes, but I want to be able to 'glue' apps with something better than connecting their ports. Otherwise we're just doing SFC graphs
09:21:33 <oanson> I don't want the l2 app to get the packet via a port and write to a port. I want to look more like a 'p4 function'
09:21:34 <dimak> I think its best to have some language for all apps
09:22:02 <dimak> But that also restricts you in some way
09:22:46 <oanson> dimak, Yes. But I think this will allow us to have better dataplane performance in the long run. I think once we use ports, we will have to pay for them.
09:23:03 <oanson> ports/interfaces/iptables/veth pairs/etc.
09:23:15 <dimak> The thing is, if we have OVS only apps, we don't have to use ports :)
09:23:19 <dimak> We can optimize that
09:23:35 <dimak> and also reorder the tables ahead of time to avoid resubmitting
09:24:03 <oanson> Then I'm confused about what you said before. Could you start over?
09:24:17 <dimak> But every so often openflow won't cut it, you'll packet-in or go to other datapath
09:25:04 <oanson> True
09:25:16 <dimak> I meant that we can define some DSL (P4) for OVS apps
09:25:22 <oanson> But I was hoping that eBPF/P4 will make these cases smaller
09:25:42 <dimak> and we don't have to pay much performance to glue those
09:25:52 <oanson> dimak, yes.
09:26:05 <dimak> But maybe we'd like to offer "bring your own datapath backend" for third party apps
09:26:41 <oanson> If they provide an DSL codeblock (e.g. P4 function, eBPF function, etc.) that's a non-issue
09:26:50 <oanson> If they want to work with a port-pair, they can use SFC
09:26:59 <oanson> (That's what it's there for)
09:27:15 <dimak> What if they want to work with a HW card on the node?
09:27:29 <irenab> or switch
09:27:33 <dimak> yeah
09:27:46 <oanson> I think most smart-nics support eBPF/P4. Dunno about switches (I think they're still OpenFlow)
09:28:42 <dimak> Anyway, I am not sure its a usecase for the cloud
09:29:51 <oanson> In the end, we want to be an application platform. That's also a cloud use-case. If you want a network functionality added, just add an app to Dragonflow. That's why we're unhappy with the SB in the first place.
09:31:50 <oanson> All right. I think we run this conversation to the ground. Any action items so far, or dimak you want to take this offline?
09:32:06 <dimak> We can take this offline
09:32:19 <dimak> I also mentioned l3 flavors earlier :)
09:32:47 <oanson> dimak, sorry. I missed that. Say again?
09:32:52 <irenab> you mean having DF Router with neutron refeence L2?
09:32:55 <dimak> Yes
09:33:11 <dimak> It would require quite a lot of heavy lifting at the moment
09:33:22 <dimak> but with SB api maybe we can do it easier
09:33:39 <dimak> it will mean that we'll have some reduced DF controller with l3+snat apps
09:33:55 <dimak> plus new app for classification/dispatch from OVS agent tables
09:34:01 <oanson> Yes. What heavy lifting is needed?
09:34:29 <dimak> Plus it means that we still need our NB database just for the agenty
09:34:42 <dimak> the l3 agent
09:34:52 <oanson> Yes. We can't do without our database.
09:35:11 <dimak> And pub-sub, though we can implement rabbit drivers and piggyback on it
09:35:15 <oanson> But using the etcd backend makes this a non-issue. etcd already exists, and by definition we can assume it's there and use it
09:35:23 <dimak> because any neutron deployment already uses rabbit
09:35:51 <oanson> Yes. pub_sub driver can be either rabbitmq or etcd. I'd prefer etcd, but both is event better :)
09:37:08 <oanson> dimak, you mentioned a design for l3 flavour (previous meeting). How is that coming along?
09:37:25 <oanson> You could mention there all the things we're missing.
09:37:37 <dimak> I think thats about it
09:37:49 <oanson> It might help us cookie-cut southbound API requirements.
09:38:16 <dimak> A southbound API can help here a lot I think
09:38:26 <dimak> To make the apps more composable
09:38:44 <oanson> classification/dispatch app should be easy (the current one is less than 100 lines)
09:39:25 <oanson> We can try making the table assignment more dynamic, for now.
09:39:30 <oanson> If needed.
09:39:32 <dimak> Yes
09:39:53 <dimak> There's also the fields we use, need to see ovs agent does that
09:40:10 <oanson> Technically dragonflow should support starting with only L3 and an snat app. It's a configuration issue. It needs to be tested though
09:40:42 <oanson> We can try to make the field names configurable
09:41:04 <dimak> Umm, will we require the ml2 plugin for port/network events?
09:41:40 <oanson> We may need a watered-down plugin here too.
09:42:02 <oanson> Might be interesting to break that apart to what we need. I think irenab's been saying that for a while now :)
09:42:16 <irenab> indeed
09:42:26 <oanson> So now we also have a use-case
09:42:40 <dimak> If we decide to push it for rocky we should have write a spec for it
09:43:02 <oanson> Rocky?
09:43:14 <oanson> Don't we have Queens first?
09:43:19 <dimak> oh right
09:43:52 <oanson> I don't know if its a lot of work. I think it's mostly gluing things we have together and testing them.
09:43:56 <oanson> Or am I missing something?
09:44:05 <irenab> there is also some mixed deployment use case, for running both ova and DF in same cluster
09:44:06 <dimak> its mostly that
09:44:19 <oanson> irenab, I think we should already support that
09:44:26 <irenab> should this have higher priority?
09:44:31 <oanson> And if we don't, we should regardless of this scenario
09:44:43 <dimak> oanson, we don't have that yet
09:44:51 <irenab> I think it may be helful for misgration from ovs to df
09:44:54 <oanson> Well, that's a shame :(
09:45:18 <dimak> We should see if ovs is going to be superseded by ovn,
09:45:30 <irenab> anyway, seems we may need some priority over all interesting items that were raised
09:45:32 <oanson> dimak, wait, what
09:45:33 <oanson> ?
09:45:56 <oanson> irenab, yes. dimak, why don't you add all this to the spec. We'll try to carve out a list of priorities and time-tables?
09:46:02 <dimak> Sure
09:46:03 <oanson> We'll see who can chip in next week.
09:46:13 <oanson> (Or during the week, if you get the spec up earlier)
09:46:18 <dimak> I'll open a bp and upload it
09:46:27 <oanson> dimak, a bug, not a bp.
09:46:46 <oanson> I think it would be best to phase the bps out. It's easier to manage the open tasks when it's in one place
09:46:58 <dimak> Ok
09:47:02 <oanson> You can add a 'feature', 'rfe', or 'blueprint' tag to the bug if you'd like
09:47:03 <dimak> I don't mind
09:47:27 <oanson> Great. Thanks.
09:47:37 <oanson> Anything else?
09:48:00 <oanson> All right, then.
09:48:10 <oanson> Thanks everyone for coming.
09:48:27 <irenab> thanks, bye
09:48:27 <oanson> #endmeeting