16:02:20 #startmeeting networking_ml2 16:02:20 Meeting started Wed Sep 10 16:02:20 2014 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:22 hi 16:02:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:24 The meeting name has been set to 'networking_ml2' 16:02:56 #link agenda https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_September_10.2C_2014 16:03:13 light agenda today, so likely a short meeting 16:03:28 #topic Announcements 16:04:11 The set of FFEs for RC-1 has been selected, and is at https://launchpad.net/neutron/+milestone/juno-rc1 16:04:33 So the focus between now and RC-1 is these BPs, plus bugs that get targetted to RC-1 16:05:11 I don’t see any unimplemented FFEs with significant ML2 impact. 16:05:22 Any questions or other announcements? 16:05:27 rkukura: I was looking for RC1 date - is it set yet? 16:05:29 Not to be an alarmist, but RC1 is 8 days away, Sept 18 16:05:34 yeah, those related already merged 16:06:14 shivharis: thx 16:06:18 #topic Action Items 16:07:05 I had an action for previous weeks to enter bugs for DVR-related issues in ML2 that I’ve discussed with armax_. 16:07:37 I entered https://bugs.launchpad.net/neutron/+bug/1367391, which is targetted at RC-1 16:07:39 Launchpad bug 1367391 in neutron "ML2 DVR port binding implementation unnecessarily duplicates schema and logic" [High,Confirmed] 16:08:20 I plan to take a shot at this right away, and see if a low risk solution is reasonable to get in. 16:09:08 Any questions on this bug? 16:10:25 The other action was for me to submit an FFE for the hierarchical port binding BP, which I did, but it was denied and will be deferred to Kilo. 16:11:07 If anyone has any feedback on the current HPB patches or design, it would be great to incorporate that into an update spec that I’ll submit for Kilo. 16:11:33 Anything else on these or any other action items I might have missed? 16:11:56 #topic Bugs 16:12:09 hi 16:12:09 shivharis: Do you want to cover this? 16:12:33 We have 8 days to get to j-rc1 16:12:49 so the time is tight and we need to pull together as a team to help push these forward 16:13:19 foremost https://bugs.launchpad.net/neutron/+bug/1193861, banix? 16:13:20 Launchpad bug 1193861 in neutron "ML2 plugin needs to override bulk operations" [Medium,In progress] 16:13:39 yes i have updated the patch 16:13:49 it now covers networks, subnets and ports 16:14:01 banix: have you done some testing? 16:14:06 a few comments on gerrit that i will address; need more review 16:14:17 what do you need fron the team? 16:14:40 folks please spend some cycles on reviews on this... 16:14:58 in particular, regarding comments on use of commit/rollback and save_and_raise 16:15:30 if amotoki could comment on gerrit it would be great as i see him as the one who wrote the related update for plugins 16:15:58 amotoki: ? 16:16:06 i mean amotoki updated plugins to use save_and_raise a while ago, not for this particular patch 16:16:16 banix: sorry I missed the context. I was chatting in neutron channel. 16:16:39 when you get a chance please have a look at #link https://review.openstack.org/#/c/113999/16/neutron/plugins/ml2/plugin.py 16:16:48 amotoki: ^^^ 16:17:20 amotoki: comments on line 496 to 499 16:17:44 also for others; I singled out amotoki because of what I mentioned above 16:17:51 Sukhdev: can you be on top of this for review as well, i'll do the same 16:18:00 Sukhdev: what testing you are referring to? 16:18:12 banix: thanks. The heart of introducing save_and_reraise everywhere is just for simplicity. It is a bit complicated case. will look 16:18:23 amotoki: thanks. 16:18:36 just a question : is there a plan to support bulk operation other than create? 16:18:51 matrohon: there are no other bulk ops 16:19:03 matrohon: only defined for create i believe 16:19:06 shivharis: I did and I will 16:19:11 banix : thanks 16:19:19 banix: Any functional testing 16:19:58 Sukhdev: not beyond my simple setup; any suggestions as how to go about this in a more systematic way? 16:20:53 Sukhdev: in other words, what would be the functional tests you want to see done 16:20:54 banix: Good question - We need to issue a bulk command and fail at least one in the middle - 16:21:14 Sukhdev: that I have done 16:21:25 banix: good 16:22:15 anything else on this, banix? 16:22:15 Aren’t in-tree functional tests typically for system interactions, which would not apply here? 16:22:40 are there functional tests along the lines of those marun has been working on that needs to be looked at? 16:22:57 rkukura: that was my understanding but i am not up to date on that front 16:23:00 rkukura: correct - they are end-to-end tests; in this case API tests will be sufficient - 16:23:14 banix: I may not be up-to-date either 16:23:18 banix, rkukura: we have one bulk api test 16:23:34 rkukura: i think that would be an integration test - but should be in tree 16:23:37 Sukhdev: Can functional tests run the client against a running configured neutron-server? 16:24:18 marun: ^^^ 16:24:31 rkukura: running configured? no 16:24:33 rkukura: that's tempest 16:24:57 rkukura: in-tree is self-contained - only targets services managed by the tests 16:25:06 marun: That’s what I thought. Are bulk create methods all tested adequately in tempest? 16:25:14 rkukura: likely no 16:25:31 rkukura: though with retargetable we could run in-tree with tempest 16:26:03 I was referrering to tempest tests - there is one bulk API test 16:26:26 Seems like a followon task to assess/improve tempest testing of bulk creates, possibly by retargetting API tests from in-tree. 16:27:11 action to talk to tempest folks regarding this 16:27:13 makes sense 16:27:23 volunteer? 16:27:30 will do 16:27:42 banix: you can look into the bulk test - see if that is sufficient or needs enhancements 16:27:52 #action banix to talk with tempest folks about bulk create testing 16:27:54 rkukura: Sukhdev yes 16:28:32 Sukhdev, banix: anything else on this? 16:28:36 Does anyone feel the existing UTs plus what banix adds in the patch is not sufficient in-tree testing for the patch to merge? 16:28:51 shivharis: I think we discussed enough - thanks 16:29:20 ok, moving on.. 16:29:21 shivharis: Any other bugs to discuss? Do we have a list of ML2 bugs targetted for RC-1? 16:29:30 rkukura: based upon what banix said, I think we are good 16:29:31 i do not have anything else, please review on gerrit 16:29:42 banix: Have started 16:29:51 rkukura: thanks 16:30:01 there a quite a few bugs targetted for RC1, i am hoping folk assigned will ask for help... 16:30:07 So, lets get this patch merged this week then 16:30:35 shivharis, others: Anything else on bugs today? 16:30:35 shivharis: are there any ml2 specific, we need to help out with? 16:30:47 Team: are there any bugs that you need help in .. bugs itself or reviews? 16:30:53 please review https://review.openstack.org/#/c/116612/ 16:30:59 banix: that is what i am asking 16:31:19 I'll wait 60 seconds for folks to send their links 16:31:24 irenab: Still has my +2 16:31:37 yes, missing one more core 16:31:56 this one still needs cores - https://review.openstack.org/#/c/105514/ 16:31:59 Need one more +2 https://review.openstack.org/#/c/89982/ 16:32:17 amotoki or mestery: Can you look at irenab’s patch? This is simple cleanup. 16:32:28 rkukura: sure 16:32:49 I'll think I will wait another 60 seconds for more links to show up 16:32:55 Here is another minor one - https://review.openstack.org/#/c/119940/ 16:33:32 rcurran: Will do 16:33:36 amotoki: thanks 16:33:50 Ok, folks I will consolidate these and put it up on the ML2 page 16:33:57 That's all from me.... 16:34:03 thanks :) 16:34:03 lets move on.. 16:34:04 shivharis: thanks 16:34:19 shivharis: Thanks 16:34:24 #topic Code Reviews 16:34:52 Is there anything else being tracked for Juno on https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews? 16:35:10 rkukura: I did not update it this week :-( 16:35:31 Considering we are past FF deadline 16:35:32 Sukhdev: Do you want to move things to the Kilo section? 16:35:44 rkukura: I can do it - 16:35:59 rkukura: you can assign me an action item for this 16:36:10 Would be nice to keep the links to the patches since many of these will be updated and continued once kilo opens and specs are approved. 16:36:51 #action Sukhdev to update Subgroup review wiki 16:37:16 Anything else on code reviews? 16:37:32 Focus is on reviewing bugs targetted at RC-1 at this point 16:37:34 https://review.openstack.org/#/c/105514/ 16:37:39 #topic Open Discussion 16:37:40 can I please get some cores for this? 16:38:19 absubram__: rcurran already asked for it - 16:38:37 absubram__: Yes, I will review that one 16:39:01 I wanted to dicuss about ML2 core resources creation/deletion by other plugin 16:39:09 matrohon: OK 16:39:21 Sukhdev, rkukra: thanks! 16:39:24 By service plugins, right? 16:39:41 yes, currently this can't happen during a transactiong because of post commit 16:39:51 matrohon: Correct 16:40:20 matrohon: For example, the GBP service plugin is structured similarly to ML2, and does these calls from precommit operations. 16:40:31 Make that postcommit, sorry. 16:40:49 that's unfair because service plugins have to roll back manually 16:41:14 matrohon: Do you have an alternative that would work with any core plugin? 16:41:18 matrohon: :) 16:41:56 any core plugin I don't know, but in ML2, post-commit could occur with sql event 16:42:38 I believe this is a good link https://bugs.launchpad.net/neutron/+bug/1367157 to understand the issue. 16:42:41 Launchpad bug 1367157 in neutron "HA network remains even if there is no more HA router" [Undecided,New] 16:43:22 this is more an excpectation, didn't coded it yet 16:43:35 those links have the same issue : https://review.openstack.org/#/c/116924/ 16:43:49 https://review.openstack.org/#/c/117287/ 16:44:27 sql event are already used to notify nova when a port goes active, in db_base_plugin_v2 16:44:28 matrohon: Long term, if we moved all ML2 postcommit processing to TaskFlow tasks, would that solve the problem? 16:45:07 that's another option that I have to investigate :) safchain told me about that too 16:45:14 matrohon: At least for ML2, using TaskFlow might make all the postcommit processing async, and enable plugin API calls within transactions. 16:45:27 But I don’t know if we could require the same of other core plugins. 16:45:47 Or of service plugins, since sometimes service plugins call other service plugins. 16:46:03 matrohon: What is your first option? 16:46:14 rkukura: I am not sure if TaskFlow will solve this 16:46:30 What do you mean by SQL event? 16:46:43 I don't have a first option, I don't know taskflow enough yet 16:47:22 the question is how to handle create just after delete (postcommit is on going). I am not sure introducing taskflow solves it. 16:47:27 matrohon: Are you suggesting the ML2 postcommit processing could be triggerred by SQL events rather than called as part of the API method? 16:47:50 rkukura : yes that the option I was invetigating 16:47:57 as it is done here : https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L77 16:48:16 rkukura : do you think it's insane? 16:48:21 but it causes long transaction... 16:48:25 amotoki: that is a fundamental issue with Neutron API - we need some sort of state to represent the progression of the operation 16:49:04 matrohon: It seems the fundemental idea is to make the postcommit processing async to the API call, and this could be done with SQL events, TaskFlow, or other approaches. 16:49:11 Sukhdev: totally agree. 16:49:46 amotoki, Sukhdev: Not sure how much of that state needs to be exposed in the API. It would be possible to use async internally. 16:50:11 for example. subsequent API calls update an existing state transition? 16:50:18 But I don’t think we want to simply let service plugins create DB records and expect everything else to be triggered by that, do we? 16:50:45 Is this issue not broader than ml2? Need broader discussion? 16:50:47 we'll need a scheduler for that 16:51:00 This sounds like a good topic for the Kilo design summit, whether specific to ML2 or more general. 16:51:02 chuckC : +1 16:51:17 rkukura: +1 16:51:18 rkukura : +1 16:51:35 rkukura: +1 16:51:41 rkukura: +1 16:51:43 rkukura: I had brought this issue during Montreal tempest sprint - and I think it requires wider discussion 16:51:52 It also ties into the backend sync / error recovery topic we’ve discussed. 16:52:10 yes indeed. sync! 16:52:21 rkukura : in previous ml2 meetings? 16:52:29 matrohon: Yes 16:52:31 I meant it is related to the sync issue as well 16:52:47 banix : +1 16:53:03 matrohon: Sukhdev and I had put together a draft doc on some ideas back before the Juno summit, I think 16:53:59 rkukura: Once Juno RC1 is over, perhaps we can discuss the plan for Kilo and propose sessions accordingly 16:54:06 rkukura : do you have the link? 16:54:09 Sukhdev: +1 16:54:21 matrohon: hang on looking 16:54:31 Shukdev : thanks 16:54:58 matrohon: will you be at the summit? 16:55:03 matrohon: here you go https://docs.google.com/document/d/17fATwZkJEonH0pIb1-mPD0UB5RKnJzcHYqkBesJhirE/edit 16:55:10 banix : yes I'm french :) 16:55:22 matrohon: cool :) 16:55:45 matrohon: so, we want to hang around with you over there - so that we are not lost :-):-) 16:56:05 rkukura: please add as action item, so we dont forget 16:56:15 Sukhdev: sounds like a smart move! 16:56:15 matrohon: Note that our thinking continued to evolve after we stopped updating that doc, so don’t take it too literally. 16:56:18 fine :) but I don't live in Paris however 16:56:36 shivharis: What’s the action? 16:56:43 rkukura : fine 16:56:58 this needs to be discussed for kilo release 16:57:12 design summit discussion 16:57:20 #action ML2 team to start thinking about Kilo design summit topics 16:57:39 perhaps we need to start an etherpad in anticipation for organizing for Kilo design sessions at some point 16:57:42 Is it time to start an etherpad or wiki to gather ideas? 16:57:55 #undo 16:57:57 Removing item from minutes: 16:59:15 #action rkukura to create etherpad for ML2-related design summit ideas, including this async postcommit processing topic 16:59:41 Any other topics for discussion? 16:59:49 nothing from me 17:00:04 rkukura: you said it will be a short meeting 17:00:07 rkukura: you said it will be short meeting - only 1 min left :-) 17:00:13 We’ve managed to use our entire hour once again - I guess thats a good sign! 17:00:22 thanks everybody 17:00:23 good discussion :) 17:00:24 #endmeeting