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