18:08:55 #startmeeting networking_policy 18:08:55 Meeting started Thu Feb 26 18:08:55 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:08:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:08:58 The meeting name has been set to 'networking_policy' 18:09:04 yapeng: s3wong: :-) 18:09:28 #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#Feb_26th.2C_19th.2C_12th.2C_2015 18:09:47 so i wanted to make a proposal up front 18:10:00 how about having a bug squashing day sometime early next week? 18:10:18 that will help us plan for the next cut of the stable release as well 18:10:58 the idea would be squash as many as high and medium priority bugs on that 18:11:07 and have reviewers handy to review and merge them 18:11:23 +1, but not on Monday (I’m flying) 18:11:29 rkukura: sure 18:11:45 we can coordinate on the day, perhaps, tuesday/wednesday 18:11:52 +1, sure, we can have it next week 18:11:54 if everyone is on board with the idea 18:11:58 +1 18:12:25 SumitNaiksatam: +1 18:12:34 note that this will also help with regards to the planned refacto (to have these bugs fixed before the refactor) 18:12:50 Yi: ivar-lazzaro: mageshgv: ok thanks for the confirmation 18:13:03 +1, wed. works for me. 18:13:19 lets tenatively plan that for tuesday or wednesday (or perhaps even thursday) 18:13:20 yapeng: thanks 18:13:36 i will reach out to everyone, and follow up with a note to the ML 18:14:05 LouisF: hi 18:14:11 SumitNaiksatam: hi 18:14:30 LouisF: FYI - we are planning a bug squashing day sometime next week 18:14:41 ok 18:14:43 okay anything else to share with the rest of the team upfront? 18:15:07 #topic Bugs 18:15:12 so still on the topic of bugs 18:15:34 one request, please check if the bugs you are fixing have a “juno-backport-potential” tag 18:15:50 and if so, please propose a cherry-pick backport patch to the stable/juno branch 18:16:17 we dont have any criticals show up during the week 18:16:31 any other bugs/fixes we need to discuss here? 18:17:02 mageshgv: and krishnaK have a couple of bug fixe patches on review 18:17:26 mageshgv: i think ivar-lazzaro had some comments for you, anything we need to discuss with the rest of the team here? 18:17:30 songole: hi! 18:17:38 Hi SumitNaiksatam 18:18:30 SumitNaiksatam: I think the comments are addressed unless ivar-lazzaro has some more comments to bring up 18:18:43 mageshgv: ah, i did not check today 18:18:45 mageshgv: will look at the review today 18:19:08 yeah, lets circle back on that 18:19:18 oh, while on that 18:19:23 one informational point to the team - 18:19:46 when creating a foreign key or unique constraints, please provide a name to those 18:20:01 there are at least a couple of places in the code where we are not doing that 18:20:15 SumitNaiksatam: +1! 18:20:17 it becomes a little bit messy to drop those constructs later 18:20:29 ivar-lazzaro: thanks for doing the investigation on this as well 18:20:36 SumitNaiksatam: magesh found a way of doing that in a backward compatible way 18:20:42 ivar-lazzaro: true 18:20:52 mageshgv: that's awesome! 18:20:53 and thats great, but i think it will still help to name 18:21:18 As a general rule it will help later if we name the constraints though 18:21:24 mageshgv: yeah 18:21:34 SumitNaiksatam: no need to name the constraints 18:21:48 mageshgv: for the fix you have, is there any chance that column names can have overlaps? 18:22:28 see https://review.openstack.org/#/c/116122/23/neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py for a migration that removes unnamed constraints 18:22:29 mageshgv: i know its not true in our case currrently 18:22:35 SumitNaiksatam: I do not think there will be any overlap issue there 18:23:07 rkukura: i am sure it can be done, as mageshgv also figured out 18:23:21 rkukura: thanks for the link 18:23:48 rkukura: i think it makes the code more readable and less prone to mistakes if the constraint is identified by a name 18:23:58 SumitNaiksatam: makes sense 18:24:30 any other bugs that we need to discuss? 18:24:46 i dont see a follow up on: 1416527 and 1417206 18:24:57 so i will check with jishnub again 18:25:28 #topic Re-factor Group Based Policy with Neutron RESTful APIs 18:25:43 so we spent another week deliberating on this 18:25:50 and i think it was time well spent 18:26:00 yes, thanks for comments. 18:26:12 meanwhile yapeng and Yi also have some WIP patches 18:26:12 I updated the spec yesterday. please review it. 18:26:28 yapeng: yes, i saw that, and I have +2’ed it 18:26:49 i think we should close on this now, and have further discussion in the implementation patches 18:27:07 if we need to revisit design, we can revise the spec by posting a follow up patch 18:27:23 SumitNaiksatam: +1 18:27:29 SumitNaiksatam: on you comment on L102 of #link https://review.openstack.org/#/c/153126/7/specs/kilo/gbp-refactor-neutron-restful-api.rst 18:27:58 SumitNaiksatam: when "self.create_policy_target" is used in the UTs, that is a wrapper for neutron-wsgi 18:27:58 ivar-lazzaro: yes 18:28:06 SumitNaiksatam: that's not a direct call 18:28:18 SumitNaiksatam: erm "neutron-plugin" call 18:28:57 SumitNaiksatam: under the hood that method does a new_create_request 18:30:07 ivar-lazzaro: is that what is being mentioned there? 18:30:13 SumitNaiksatam: so as long as the UTs client wrapper uses neutron-wsgi calls, we should be ok 18:30:30 "When a call such as "create_policy_target" [1] is made in the RMD UT, the RMD implementation is making a neutron-plugin call." 18:31:00 SumitNaiksatam: did I understand it wrong? 18:31:31 ivar-lazzaro: checking 18:31:52 ivar-lazzaro: I think this is the current implementation.. 18:33:34 ivar-lazzaro: by neutron-plugin calls i am referring to #link https://github.com/stackforge/group-based-policy/blob/master/gbpservice/neutron/services/grouppolicy/drivers/resource_mapping.py#L1358-L1416 18:34:21 SumitNaiksatam: ok, that seemed to be referring to the UT implementation 18:34:27 SumitNaiksatam: thanks for the clarification 18:34:32 ivar-lazzaro: okay 18:35:14 ivar-lazzaro: ah i see, i put [1] as a reference to the UT calls 18:36:03 okay so anyone not on board to make progress with the way the current spec is defined? 18:36:41 +1 18:37:06 s3wong: thanks :-) 18:38:10 okay, so unless there are any other major concerns lets close on this spec today 18:38:27 cores - request you to take a look at the earliest and push this forward 18:38:28 SumitNaiksatam: I can review the spec one more time today and give the second +2 18:38:41 s3wong: okay great, thanks! 18:39:50 #topic Floating IP support 18:39:58 #undo 18:39:59 Removing item from minutes: 18:40:16 just realized that i did not post the link of the refactoring spec... 18:40:32 so belatedly - #link https://review.openstack.org/#/c/153126 ;-) 18:40:47 #topic Floating IP support 18:40:58 #link https://review.openstack.org/157298 18:41:06 i think mageshgv dropped off 18:41:37 myself and ivar-lazzaro reviewed this, and we are waiting for mageshgv to post the next patch set 18:41:53 anyone else had a chance to look at the above spec? 18:41:59 questions/comments? 18:42:19 i believe songole is here and might be able to address those on mageshgv’s behalf 18:42:28 SumitNaiksatam: I have not yet, but will 18:42:34 rkukura: great, thanks 18:42:48 SumitNaiksatam: I have not reviewed yet. I will review. 18:42:58 songole: ah okay :-) 18:43:18 rkukura: songole any chance that you guys can review this by EoD? 18:43:28 ok 18:43:50 that way when mageshgv is back by evening our time, he can post a consolidated/updated patch set 18:44:16 SumitNaiksatam: OK 18:44:34 rkukura: thanks 18:45:14 rkukura: over to you for the next two topics 18:45:16 #topic Taskflow investigation 18:45:31 you mentioned you are reviewing the neutron patches 18:45:37 and gaining better understanding 18:46:02 I haven’t made any progress on this since last week, but will get to it shortly 18:46:21 I’d also like to look at how other projects are using TaskFlow 18:46:29 rkukura: sure 18:46:42 rkukura: would it help if we have a sesson with manish next week? 18:46:48 since you are going to be here? 18:46:58 i can try and reach out to him 18:47:28 rest of the team can also participate 18:47:34 SumitNaiksatam: could be a good idea, but lets see when we schedule the bug squashing first 18:47:58 rkukura: yes sure, we can do those on separate days 18:48:14 okay so two action items for me in terms of planning for next week 18:48:15 I think we may have some different requirements with the need to validate and implicitly create resources before transactions, ... 18:48:23 rkukura: sure 18:48:46 rkukura: thanks for the update 18:48:51 np 18:49:05 #topic Packaging update 18:49:20 i believe no developments on the RH/Fedora packing, right? 18:50:08 rkukura: ^^^ ? 18:50:12 SumitNaiksatam: one 18:50:33 The heat package’s dependencies have become out of date, so this needs an update 18:51:03 would be nice to update to stable releases for everything at the same time 18:51:20 rkukura: ah, was just asking if we needed to cut a new stable 18:51:45 Its actially the horizon package, not heat 18:51:45 so on that, susaant has made a couple of fixes in gbpautomation which should be backported 18:52:01 rkukura: ah okay 18:52:18 i will be posting a fix in horizon as well 18:52:37 and it might just be that fedora rawhide has already moved to a kilo milestone - need to investigate 18:52:56 rkukura: okay 18:52:59 how about if we target end of next week for stable update? 18:53:15 after we’ve squashed and backported bugs 18:53:21 rkukura: sure, end of next week 18:54:10 so horizon we can cut new stable after i post the patch 18:54:14 please watch out for that 18:54:35 was just looking at the broken dependency email - I think we will need kilo-compatible versions to resolve this 18:54:51 rkukura: oh, thats tricky 18:54:58 rkukura: lets discuss offline 18:54:59 but this issue is just with Fedora rawhide (F22) right now, not RDO, which is still Juno 18:55:08 rkukura: whew! 18:55:36 slightly off current-topic, but since we brought up heat - susaant has two important bug fixes waiting to be reviewed: 18:55:44 #link https://review.openstack.org/155096 18:55:51 #link https://review.openstack.org/155153 18:55:58 if anyone has time, please review 18:56:13 the above will need to be backported 18:56:29 there is another one which is for a namespace change: #link https://review.openstack.org/155172 18:56:35 which will not be backported 18:56:44 also regarding the Ubuntu packages 18:57:05 we have not documented the install process (similar to what has been done for RH/Fedora) 18:57:13 i think magesh tried this and has some notes 18:57:18 he will be posting them on the wiki 18:57:28 but if anyone else has tried this, please chime in 18:57:33 on the wiki page 18:57:51 this would be the place to put it: #link https://wiki.openstack.org/wiki/GroupBasedPolicy#Try_Group-based_Policy 18:57:57 #topic Open Discussion 18:58:33 LouisF: nicolas mentioned that there was someone from his team who was going to follow up on your blueprints 18:58:40 LouisF: havent seen acitivity there 18:59:20 anything else anyone want to discuss? 18:59:32 grand total of one min remaining ;-) 19:00:19 okay, i guess nothing more for today 19:00:24 anyone using the extension driver APIs? 19:00:33 rkukura: not yet 19:00:44 need to check with banix 19:00:50 some changes in the neutron version of those we might want to pull in 19:00:53 and i think ivar-lazzaro also plans to use 19:01:09 lets take it to #openstack-gbp 19:01:13 thanks everyone 19:01:16 bye! 19:01:21 ciao! 19:01:31 bye! 19:01:34 #endmeeting