09:00:17 <oanson> #startmeeting Dragonflow
09:00:18 <openstack> Meeting started Mon Mar  6 09:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:21 <openstack> The meeting name has been set to 'dragonflow'
09:00:43 <xiaohhui> hello
09:00:49 <nick-ma> Hello
09:00:53 <oanson> nick-ma, xiaohhui, hi
09:00:58 <lihi> Hi
09:00:58 <dimak> Hello
09:01:08 <oanson> We'll wait another minute to let everyone join
09:01:24 <irenab_> hi
09:02:45 * yuvalb observes quietly
09:02:51 <oanson> All right. I guess we can start
09:03:03 <oanson> #info xiaohhui nick-ma lihi dimak irenab ishafran in meeting
09:03:11 <oanson> #info yuvalb observing meeting
09:03:17 <oanson> #topic Roadmap
09:03:46 <oanson> We have a few lay-overs from Ocata into Pike. Actually it's all the big stuff
09:04:10 <oanson> IPv6 - lihi, I understand that we're just missing the fullstack test and we're go?
09:04:58 <lihi> yes, The ping pong and the rest of the test are almost done. Will be up today
09:05:05 <oanson> Great!
09:05:14 <lihi> (however be prepared for another 300~ seconds test to the ci)
09:05:53 <oanson> We'll have to see. If it is getting too long, maybe we'll split the gate jobs - one for flow based, and one for end-to-end based tests
09:05:58 <oanson> But that's a long way ahead.
09:06:23 <oanson> NB refactor - It is almost complete. We have also started porting models over.
09:06:33 <oanson> Give me a second to find the right etherpad :)
09:06:36 <dimak> I have some reservations on tests that check flows are there
09:06:50 <dimak> https://etherpad.openstack.org/p/df-refactor-models
09:06:54 <dimak> oanson, ^^
09:07:11 <oanson> #link Model porting status https://etherpad.openstack.org/p/df-refactor-models
09:07:40 <xiaohhui> It is free to pick the porting job, right? I would like to play with one or two models.
09:07:40 <oanson> So Chassis was already ported.
09:07:45 <oanson> Yes
09:08:02 <xiaohhui> Great!
09:08:07 <oanson> xiaohhui, I think the router stuff is free.
09:08:21 <oanson> Note that lport relies on lswitch, subnet, and secgroups
09:08:52 <xiaohhui> I will check the router.
09:09:02 <oanson> I did most of the work on lswitch and subnet, and I want to assign secgroups to lihi
09:09:19 <lihi> Sure
09:09:22 <oanson> lihi mentioned that she wants to review the sg app, so it would work well together
09:09:37 <oanson> Please add yourselves to the list.
09:10:27 <xiaohhui> Done
09:10:37 <oanson> Thanks
09:10:51 <lihi> also done
09:10:56 <oanson> sNAT - there is a patch up. It looks ready for review. I tested an earlier version and it seems to work
09:11:16 <oanson> #link snat patch https://review.openstack.org/#/c/431422/
09:11:20 <ishafran> All comments are addressed, including fulstack test
09:11:33 <oanson> ishafran, cool. Thanks!
09:11:59 <irenab_> oanson, once I verify, will post +1
09:12:09 <oanson> irenab_, great. Thanks!
09:12:14 <oanson> Chassis/Service health - rajivk informed me that he was pulled from Dragonflow, so someone has to take over that one
09:12:31 <oanson> It's interesting for the feature itself, and for the Service base class
09:12:41 <oanson> Do we have any volunteers?
09:12:46 <xiaohhui> I think I can take it
09:13:00 <oanson> xiaohhui, great. Thanks!
09:13:09 <oanson> #link Added support for service status reporting https://review.openstack.org/#/c/415997/
09:13:40 <xiaohhui> Got it.
09:13:49 <oanson> TAPaaS is frozen for now. Since it's not a major feature, I suggest we put it on hold.
09:13:52 <oanson> Unless there are objections?
09:14:40 <oanson> All right.
09:15:16 <oanson> Regarding API, once the migration to new NB models is partly complete, we can start testing the autogenerated API.
09:15:21 <oanson> irenab_, this one is on you?
09:15:38 <irenab_> irenab, ok
09:15:43 <irenab_> oanson, ok
09:15:53 <oanson> Cool. Thanks!
09:16:06 <oanson> New features for Pike:
09:16:30 <oanson> VLAN over VMs - I'm taking this one. I uploaded a WIP patch, but it relies on the migration of lport to NB models.
09:17:04 <irenab_> oanson, when do you think it will be possible to experiment with this?
09:17:30 <oanson> irenab_, I am hoping in 2 weeks.
09:17:39 <oanson> It mostly depends on how well the migration goes.
09:17:42 <irenab_> cool, thanks
09:17:46 <dimak> oanson, s/over/aware/
09:18:02 <oanson> dimak, sorry?
09:18:10 <oanson> dimak, Yes.
09:18:15 <oanson> VLAN *aware* VMs.
09:18:56 <oanson> RPM packaging - I have met with the packaging people in the PTG. Their very nice. They told me where to start and what to do
09:19:08 <oanson> dimak, you're taking this, right?
09:19:10 <dimak> Yes
09:19:34 <dimak> I've started tinkering with it a bit but it'll take some time until I have some progress to show
09:19:48 <oanson> dimak, sure.
09:20:01 <oanson> There's also the SFC on you, so no rush.
09:20:12 <oanson> Next is puppet deployment, which will also be used for TripleO deployment. lihi, this one is on you, right?
09:20:36 <lihi> Yes.
09:21:04 <oanson> We should also have a multinode gate test. I spoke with infra about that too. It doesn't seem to complex, but it will need a carrier.
09:22:14 <oanson> We should also have a get for the ansible deployment. But the ansible deployment is broken :(.
09:22:39 <oanson> Once the ansible deployment works again, it shouldn't be a problem to add the gate to our list
09:23:16 <oanson> There are also goals for LBaaS and documentation, but I think we're out of hands at the moment, so let's wait with those until we cleared the queue a bit.
09:23:34 <oanson> I'll make an etherpad with a summary of all this, and publish it in the channel and next meeting (and add it to the agenda)
09:24:09 <oanson> This is acceptable to everyone? Anything that should be pushed forwards and isn't?
09:24:46 <dimak> You missed the SFC part :P
09:24:49 <oanson> btw LBaaS hopefully will be a collaboration effort with octavia team.
09:24:56 <dimak> Its getting quite ready, so I'd love some input
09:24:57 <oanson> dimak, sure
09:25:13 <irenab_> oanson, please also update on interop
09:25:36 <itamaro> I'd like to discuss the idea of making the ICMP and TTL mgmt as a sparate app
09:25:48 <oanson> irenab_, I don't have all the information of the top of my head. If someone can fill in, that would be great.
09:26:13 <irenab_> oanson, maybe some summary later based on the info you got during PTG
09:26:29 <oanson> Sure. I'll put it in the channel
09:26:56 <oanson> itamaro, sure, go ahead
09:27:42 <itamaro> I mainly think that DNAT should only do DNAT
09:28:26 <itamaro> and all L3 related functions such as ICMP and TTL moved to a dediicated application
09:29:36 <xiaohhui> What if user don't add l3 app, how will the dedicated application work?
09:30:02 <itamaro> dependecy.
09:30:28 <itamaro> It should depend on the ecistence of either DNAT/L3
09:31:07 <itamaro> it also can depend on exiting flows in a dedicated table
09:31:41 <oanson> itamaro, will the ICMP/TTL app behave the same under a different L3/dNAT/sNAT implementation?
09:32:25 <dimak> Maybe it can be something installable like an arp responder?
09:32:41 <itamaro> It should, but need to investigate in order to provide a common functionality
09:32:49 <xiaohhui> The message generation should be the same, but details should be different.
09:32:56 <itamaro> dimak -> yes
09:33:15 <itamaro> agree
09:33:30 <itamaro> with xiaohhui
09:33:30 <oanson> The ICMP generation is already in a library
09:33:51 <dimak> Have an app that monitors packet_in from a specific table, then add installable redirector
09:33:51 <oanson> Maybe just move the ICMP inner-NATting code to the library as well?
09:34:36 <oanson> dimak, applications already register to packet-in from a specific table
09:34:48 <xiaohhui> responder might not be feasible. The packet construction is too complex for a rule in OpenFlow.
09:34:51 <dimak> No I meant that you have a ttl responder app
09:35:16 <dimak> and ttl responder redirector that route ttl=0 packets to app's table with some reg to note what app did it
09:35:27 <itamaro> I agree with both dimak's suggestions
09:35:51 <oanson> dimak, OVS sends a packet-in message automatically if the TTL hits 0. This way we don't have to detect it manually
09:36:17 <oanson> We can add code to detect the event and move it to a specified application, rather than by table number
09:36:35 <oanson> (Like the code that exists today in L3)
09:36:42 <dimak> We'll need to figure it out, maybe match on ttl=1 prematurely
09:37:01 <dimak> Thats also a possibility
09:37:26 <oanson> I think letting OVS do the filtering for us is better - less error-prone.
09:37:36 <xiaohhui> it looks like ryu doesn't provide ttl match, thought it is supported in ovs
09:37:41 <dimak> I think if we decide to tackle it we can come up with a way to consolidate all the treatment into a designated app
09:37:47 <xiaohhui> thought -> though
09:38:46 <itamaro> xiao, dimak would u like to take it together with me
09:38:58 <dimak> itamaro, sure
09:39:34 <xiaohhui> sure, I will review the code, if it comes up.
09:39:44 <oanson> itamaro, dimak, xiaohhui, in your solution, please try to use OVS's automatic TTL expiry detection method. I'd rather not maintain a heuristic for something that OVS gives us for free
09:39:55 <dimak> +1
09:40:11 <oanson> And this way we don't need ryu's missing ttl matching support
09:40:34 <oanson> itamaro, this one's on you :)
09:40:44 <itamaro> ok
09:40:49 <xiaohhui> I agree with oanson, that is also an feature described in openflow 1.3 spec. We should use it.
09:41:32 <oanson> Great.
09:41:47 <oanson> Anything else for roadmap?
09:42:29 <oanson> #topic Open Discussion
09:42:38 <itamaro> I wanted to talk about the app  tag feature
09:42:47 <oanson> itamaro, sure, go ahead
09:43:16 <itamaro> I have tried to do a full stack test. but it looks rather compilcated
09:43:41 <itamaro> as the test does not share the same memory as the apps
09:44:09 <nick-ma__> Sorry, I am in the train.  my network is not stable. I didn't get most of the discussion. I will quit and check the log. g
09:44:25 <oanson> nick-ma__, we just started this topic
09:44:38 <itamaro> as it is a debug feature which is based on well tested cockie manipulation  mechnism
09:44:51 <itamaro> maybe a unit test will suffice
09:44:54 <oanson> itamaro, it will at least need a unit test
09:45:19 <itamaro> yes
09:45:51 <oanson> Since nick-ma brought up the fullstack test issue, I would like to get an OK from him that a unit test is enough
09:46:18 <oanson> Let's wait a minute till he returns and continue this one.
09:46:24 <oanson> Any other items, in the meantime?
09:47:18 <oanson> Any reviews you feel should get special attention?
09:47:28 <dimak> Ummm
09:47:38 <dimak> I came across skydive this morning
09:47:38 <xiaohhui> I have one
09:47:54 <dimak> Its a network monitoring tool that integrates with neutron
09:48:02 <oanson> dimak, link?
09:48:07 <xiaohhui> https://review.openstack.org/#/c/440946/
09:48:14 <dimak> https://github.com/skydive-project/skydive
09:48:34 <irenab_> dimak, I checked this project a while ago
09:48:51 <oanson> xiaohhui, sure. I'll look at it
09:49:01 <dimak> I've tried to deploy it in my devstack and it went OK, but there are some things that I failed to do, like pinging between ports
09:49:08 <xiaohhui> Thanks!
09:49:27 <dimak> They say they are SDN agnostic though provide drivers for various neutron implementations
09:49:46 <dimak> Maybe its worthwhile adding some support for dragonflow
09:49:54 <irenab_> dimak, +1
09:50:12 <oanson> xiaohhui, done. +WFed
09:50:29 <xiaohhui> Thanks!
09:50:31 <irenab_> according to the project irc, links are: Skydive is hosted on http://softwarefactory-project. Github: https://github.com/redhat-cip/skydive
09:50:45 <oanson> dimak, yes. Troubleshooting features are very important, and a pain point for providers
09:52:07 <dimak> I still haven't looked into it too much, but it looks quite nice
09:53:05 <oanson> dimak, so what were you thinking? Add a Dragonflow driver? Add documentation on how to integrate?
09:53:26 <dimak> oanson, well, first figure out what's missing
09:53:37 <dimak> Maybe both
09:54:23 <irenab_> dimak, I think it already supports ODL as SDN backend
09:55:35 <oanson> itamaro, it looks like nick-ma isn't coming back. Please contact him offline
09:55:42 <itamaro> ok
09:55:53 <oanson> dimak, sounds like a plan. Do you have time to take it?
09:56:28 <dimak> I wanted to check it out in context of SFC testing
09:56:37 <oanson> Sounds cool
09:56:43 <dimak> I'll see how much effort it requires and report back
09:56:55 <oanson> Sure. Sounds good.
09:57:12 <oanson> Anything other items?
09:58:38 <oanson> Great.
09:58:40 <oanson> Thanks everyone!
09:58:52 <oanson> #endmeeting