09:00:22 <oanson> #startmeeting Dragonflow
09:00:23 <openstack> Meeting started Mon Dec  5 09:00:22 2016 UTC and is due to finish in 60 minutes.  The chair is oanson. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:26 <openstack> The meeting name has been set to 'dragonflow'
09:00:29 <dimak> Good morning
09:00:36 <xiaohhui> Heel
09:00:40 <xiaohhui> Hello
09:00:43 <oanson> Hi
09:00:45 <hujie> Hi
09:01:04 <oanson> Agenda is here: https://wiki.openstack.org/wiki/Meetings/Dragonflow
09:01:13 <irenab> hi
09:01:42 <yuli_s> hello
09:01:44 <lihi> Hi
09:01:50 <oanson> #info dimak xiaohhui hujie irenab yuli_s lihi is in meeting
09:02:04 <oanson> All right. Let's get this show on the road
09:02:12 <oanson> #topic Ocata Roadmap
09:02:27 <oanson> lihi, you want to update us on IPv6?
09:03:24 <lihi> There is an issue with the fullstack tests and IPv6
09:04:00 <lihi> I'm working on that. Should upload a patch soon
09:04:30 <oanson> Great.
09:04:35 <lihi> After that I'll be able to write the tests for the NS responser
09:04:43 <oanson> Anything that makes fullstack more stable is very well accepted :)
09:04:55 <lihi> And then I'll upload it too
09:05:03 <oanson> Great. Thanks!
09:05:12 <oanson> dimak, any news on SFC?
09:05:38 <dimak> I've uploaded some patches that don't do much yet
09:06:03 <dimak> mainly code that connects sfc drivers with the ryu apps though nb api
09:06:23 <dimak> I have some ideas to remove duplicate code around NB api and db store
09:06:43 <dimak> and maybe make ryu app base slimmer
09:06:51 <oanson> Great.
09:06:53 <lihi> sounds good
09:07:08 <dimak> some of this is in https://review.openstack.org/#/q/status:open+project:openstack/dragonflow+branch:master+topic:bp/service-function-chaining
09:07:08 <hujie> +1
09:07:34 <oanson> dimak, that code is WF-1. Should we start sending comments? Or wait till it's more mature?
09:08:02 <dimak> I'll move the refactoring code underneath all the sfc stuff
09:08:17 <dimak> so it can be reviewed without the sfc noise
09:08:25 <dimak> and get in without waiting for sfc
09:08:30 <oanson> If your changes are not directly related, you can just place them in unrelated patches
09:08:50 <oanson> If you then need two changes as parents, you can use the Depends-On commit tag.
09:08:51 <oanson> If that helps
09:09:03 <dimak> Oh, I'll try that :)
09:09:21 <dimak> thats about all
09:09:24 <oanson> I noticed that when the patch chains get too long, it becomes a headache to maintain, especially for the developer
09:09:34 <dimak> I'll update when I have more concrete
09:09:40 <oanson> Great. Thanks!
09:09:52 <dimak> I prefer longer chains with concrete changes :)
09:10:01 <oanson> Up to you
09:10:05 <oanson> :)
09:10:18 <oanson> Chassis liveness
09:10:21 <oanson> xiaohhui?
09:10:35 <xiaohhui> I haven't started yet
09:10:57 <xiaohhui> I plan to do it after virtual tunnel port
09:10:59 <oanson> No worries. I see you are doing a lot of other things in parallel :)
09:11:18 <oanson> Wasn't that merged?
09:11:30 <xiaohhui> As they both changes lots of stuff of chassis
09:11:39 <xiaohhui> Not all the code
09:12:01 <oanson> I see.
09:12:02 <xiaohhui> I put some other code in the review board
09:12:50 <oanson> I see
09:13:09 <xiaohhui> I am on my mobile, so I can't put the link here
09:13:28 <oanson> #link virtual tunnel port support https://review.openstack.org/#/q/project:openstack/dragonflow+branch:master+topic:bp/virtual-tunnel-port-support
09:13:36 <xiaohhui> But that should be ok for the status
09:13:48 <xiaohhui> Thanks oanson
09:13:54 <oanson> np :)
09:14:11 <xiaohhui> I mean that should be all for the status
09:14:55 <oanson> rajivk, I see there are some comments on the service status reporting spec
09:15:03 <oanson> Anything that needs to be discussed here?
09:15:11 <oanson> (Also hujie, nick-ma_ )
09:15:18 <rajivk> I would like more comments
09:15:45 <irenab> rajivk: link tothe patch?
09:15:57 <rajivk> i have put different approaches for a few things, if someone can comment on them, it will be great.
09:16:01 <oanson> #link service status reporting spec https://review.openstack.org/#/c/402395/
09:16:15 <oanson> All right. I'll review it by tomorrow
09:16:29 <hujie> I'm do some refactor job and bug fix, and I plan to commit db consistent logic between neutron db and df db
09:16:32 <rajivk> If that is ok, i will put updated patch for it.
09:16:32 <xiaohhui> I will check it.
09:17:19 <nick-ma_> hi alll
09:17:25 <lihi> I'll also check it
09:17:25 <oanson> hujie, I'm looking forward to it :)
09:17:35 <hujie> :)
09:17:43 <oanson> I'm interested to know how you wrote it, since it will be useful for migration too
09:17:47 <oanson> nick-ma_, hi
09:18:46 <hujie> ok, but the main logic is similar to the south:)
09:18:59 <oanson> That makes sense
09:19:19 <oanson> I'm guessing it will sit on the Neutron service, or its own service?
09:19:27 <hujie> yes
09:19:38 <hujie> a separate service
09:19:51 <oanson> Sounds great
09:19:57 <hujie> :)
09:20:11 <oanson> TAPaaS - yuli_s any comments? Anything that needs to be discussed here?
09:20:28 <yuli_s> sure
09:20:57 <yuli_s> please take a look at the last version of spec
09:21:00 <yuli_s> https://review.openstack.org/#/c/396307/
09:21:15 <oanson> #link TAP as a service spec https://review.openstack.org/#/c/396307/
09:21:50 <oanson> I see a lot of work was done yesterday :)
09:21:54 <oanson> I'll review it today too
09:21:57 <yuli_s> yes !
09:22:12 <yuli_s> thanks,
09:22:24 <oanson> I also saw that the position variable issue was resolved
09:22:32 <oanson> Which is also great
09:22:36 <yuli_s> yes,
09:22:54 <yuli_s> and we have a solution for cycles
09:23:01 <yuli_s> of packets
09:23:13 <oanson> Care to share?
09:23:13 <yuli_s> as opposed to neutron
09:23:24 <yuli_s> yes, check the document
09:23:54 <oanson> All right. I'll stay in suspense until I do :)
09:24:03 <yuli_s> ok ;)
09:24:22 <oanson> ishafran, any news about anonymous sNAT?
09:24:48 <oanson> I saw that the spec was updated earlier too
09:24:54 <ishafran> I would like to get latest patch set #9 of spec approved
09:24:54 <oanson> Anything that has to be discussed here?
09:25:23 <ishafran> nothing except spec :)
09:25:40 <oanson> All right. I'll look at it as well :)
09:26:07 <oanson> denghui isn't here to discuss LBaaS, so we'll skip it this week.
09:26:42 <oanson> I think I reached a stable state in Dragonflow deployment with OSA
09:27:02 <nick-ma_> great news.
09:27:04 <oanson> #link Openstack-ansible dragonflow patch https://review.openstack.org/#/c/391524/
09:27:24 <oanson> I am now waiting for reviews. If anyone wants to try it out and find all the hidden bugs I put in :)
09:28:00 <dimak> I'll try to deploy it :)
09:28:00 <oanson> Anything else for roadmap?
09:28:12 <oanson> dimak, go for it! Wear a hard-hat :)
09:29:07 <oanson> They have a tox environment (tox -e dragonflow) that installs the bare minimum
09:29:13 <oanson> including neutron and dragonflow
09:29:41 <oanson> Anything else for roadmap?
09:30:03 <qwebirc45930> Have you guys had a chance to review the new classifier spec
09:30:10 <qwebirc45930> ?
09:30:20 <irenab> yes, I did
09:30:32 <hujie> I have reviewed it :)
09:30:48 <hujie> any problem?
09:31:00 <oanson> #link Separation Classification app spec https://review.openstack.org/#/c/404622/
09:31:43 <oanson> qwebirc45930?
09:32:09 <qwebirc45930> So  how should we continue with it?
09:32:18 <oanson> All right. It looks like its pretty far along.
09:32:52 <oanson> We'll wait for a few more reviews.
09:33:01 <oanson> If there are no objections, we'll merge it later this week
09:33:28 <qwebirc45930> Great
09:33:33 <nick-ma_> i will review it later.
09:33:54 <oanson> nick-ma_, thanks!
09:34:07 <oanson> Anything else for roadmap?
09:34:50 <oanson> #topic Bugs
09:35:09 <oanson> There are bugs.
09:35:47 <hujie> https://review.openstack.org/#/c/406751/
09:35:51 <oanson> But as I said a few weeks ago, I want to concentrate on features and code cleanup now. And crack down on bugs later (say 2-3 weeks from now)
09:36:22 <hujie> dpdk config bug :)
09:37:07 <oanson> hujie, fullstack fails in that patch. Connection to Neutron fails (at a quick glance)
09:37:38 <nick-ma_> yes, i'm checking it.
09:37:45 <hujie> ok I see
09:37:57 <rajivk> oanson, if you need my help for code cleaning, i am available.
09:38:14 <oanson> rajivk, thanks.
09:38:39 <oanson> I'll have to get back to you - there is a lot of work done by xiaohhui, dimak, and hujie, and I got a bit lost at who's doing what :)
09:39:27 <rajivk> oanson, i will try my best to help you :)
09:39:36 <oanson> Thanks! Greatly appreciated!
09:39:51 <oanson> Anything else for bugs?
09:39:57 <rajivk> https://review.openstack.org/#/c/320398/
09:40:25 <rajivk> I have submitted patch for it. i am having problem for fullstack tests.
09:40:58 <rajivk> Can someone help me with them?
09:41:23 <xiaohhui> I have a similar patch. Maybe you could use it
09:41:36 <xiaohhui> I am still on mobile
09:41:40 <rajivk> :)
09:41:43 <oanson> rajivk, I can look into it as well
09:41:55 <rajivk> thanks
09:42:01 <oanson> xiaohhui, do you remember the name of the patch, and I'll add the link?
09:42:13 <xiaohhui> Dhcp options
09:42:25 <xiaohhui> I try to add some other dhcp options
09:43:04 <rajivk> May be we can list down, all the options and take them one by one.
09:43:04 <oanson> #link Support default route from port extra dhcp options https://review.openstack.org/#/c/401964/1
09:43:27 <xiaohhui> Yes, this one
09:43:34 <oanson> Maybe a list/map from option name to function that generates option data,
09:43:44 <oanson> if the function returns none, skip that option
09:43:58 <oanson> I am now working on a big refactor for dhcp app.
09:44:01 <oanson> I'll add it there
09:44:07 <oanson> (Or as a followup)
09:44:56 <oanson> Anything else for bugs?
09:45:41 <oanson> #topic Open Discussion
09:46:30 <oanson> @snapiri suggested we review the code in df_local_controller
09:46:49 <oanson> Many functions (mostly delete) receive object IDs only to fetch them from db_store
09:47:06 <oanson> And many callers of these functions already have the object available.
09:47:28 <oanson> snapiri suggests duplicating the api - one for id, and one for object (since there is no real overloading in python)
09:47:47 <oanson> The ID api can call the object api, so there shoudn't be code duplication.
09:47:49 <oanson> Any thoughts?
09:48:22 <dimak> sounds reasonable
09:48:36 <dimak> there is also a lot of 'create or update' code
09:48:52 <dimak> fetch original => check if none => check version
09:49:04 <dimak> maybe we can do something about it
09:49:24 <hujie> this patch is my first step to refactor the code: https://review.openstack.org/#/c/406114/
09:49:47 <hujie> I'll use update instead of create/update method
09:50:28 <oanson> Sounds like the right direction.
09:50:33 <rajivk> hujie: your patch is very big, can you please break it into smaller pieces, it will help in reviewing.
09:50:47 <oanson> I would have preferred to keep them separated, but it really looks like the two methods are always very similar
09:51:25 <rajivk> i would prefer separated one's as well.
09:51:28 <hujie> yes, it's very similar :)
09:51:43 <rajivk> May be we can create one more method, which has common code.
09:52:06 <rajivk> and both of the original method call's it. What do you think?
09:52:17 <oanson> We will have to review how each solution pans out, and select the best one.
09:52:22 <oanson> In general this sounds like a good idea.
09:52:44 <oanson> We should just make sure we don't end up with two identical functions calling the common code, just to keep the create/update separation
09:52:44 <hujie> I have deleted the create method indeed :)
09:53:16 <oanson> Maybe a fallback for create? on create call the create method, and if it doesn't exist, call the update method?
09:53:58 <dimak> we can but I'm not sure a standalone create method is justified here, update has to take care of create anyway
09:54:03 <hujie> I think update is enough, while other resources have the update/delete method to cover all the scenario
09:54:12 <oanson> dimak wrote a _CRUDHelper class which holds stubs for create and update (for nb_api, but he says there should be a similar one for df_controller). Maybe something along these lines?
09:54:44 <oanson> All right. Then lets stick to update only. We can always add create methods later, on in specific cases
09:54:49 <dimak> 1 sec I'll send a link
09:54:59 <hujie> ok great
09:55:16 <dimak> https://review.openstack.org/#/c/406599/1/dragonflow/db/api_nb.py
09:55:35 <oanson> #link CRUDHelper https://review.openstack.org/#/c/406599/1/dragonflow/db/api_nb.py
09:56:21 <oanson> Anything else on this?
09:56:32 <oanson> The floor is for the taking.
09:57:13 <oanson> All right. Great meeting. Great work!
09:57:27 <oanson> I think its a good sign that there is so much being done that I can't keep up :)
09:57:30 <dimak> Thanks, good bye!
09:57:33 <nick-ma_> thanks.
09:57:38 <irenab> thanks
09:57:39 <rajivk> thanks
09:57:40 <lihi> Thanks
09:57:40 <hujie> thx bye
09:57:41 <xiaohhui> Bye
09:57:47 <oanson> #endmeeting