15:02:47 <ihrachys> #startmeeting neutron_upgrades
15:02:48 <openstack> Meeting started Mon Jun 27 15:02:47 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:48 <rossella_s> :)
15:02:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:51 <ihrachys> o/
15:02:52 <openstack> The meeting name has been set to 'neutron_upgrades'
15:03:00 <korzen> hello
15:03:03 <rossella_s> hi
15:03:06 <dasm> o/
15:03:09 <jlibosva> o/
15:03:35 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:03:44 <ihrachys> #topic Actions from the last meeting
15:03:55 <ihrachys> "korzen to spin up a devref patch describing base neutron object class features, testing interface, tips&tricks, etc."
15:04:06 <korzen> did not happen
15:04:21 <korzen> I'm planning to do it this week, maybe tomorrow
15:04:35 <ihrachys> korzen: will you have time for that this week, or maybe you prefer to stick to code?
15:04:57 <ihrachys> ok, let's have it repeated then
15:04:58 <ihrachys> #action korzen to spin up a devref patch describing base neutron object class features, testing interface, tips&tricks, etc.
15:07:06 <ihrachys> there is no formal action item on that one, but I was to look at dvr job voting. did not really happen since I was off most of the previous week.
15:07:06 <ihrachys> putting it here for the next time.
15:07:19 <ihrachys> #action ihrachys to make progress on dvr grenade job voting
15:09:06 <ihrachys> I have no announcements.
15:09:07 <ihrachys> I also think we have nothing for partial grenade job, due to the reason above
15:09:07 <ihrachys> skipping those
15:09:07 <ihrachys> #topic Object implementation
15:09:07 <ihrachys> that one may be more interesting.
15:09:07 <ihrachys> rossella_s: korzen: since I was off, may some of you update on latest developments on objects front?
15:09:07 <korzen> so I was struggling with subnet OVO integration and found 2 major issues
15:09:08 <rossella_s> ihrachys, I don't have much to report, I've reviewed some patches, that's is, I was busy with the opnfv summit
15:09:08 <rossella_s> korzen, tell us more
15:09:08 <korzen> 1) limit the sql queries number when loading the synthetic fields
15:09:08 <korzen> #link https://review.openstack.org/#/c/334380/2
15:09:58 <korzen> it is scaling problem, number of queries are increasing when you add new subnets
15:10:09 <ihrachys> so you reuse relationships to construct object-fields.
15:10:43 <korzen> ihrachys, yes the synthetic fields are already loaded, no need to query for them
15:11:05 <ihrachys> I think that makes sense, and we will need to solve that. the patch seems sane.
15:11:18 <rossella_s> thanks korzen
15:11:19 <ihrachys> what's the 2nd issue?
15:11:44 <korzen> 2) filter_by in get_object was not applying the filter correctly
15:11:57 <korzen> when having RBAC entries
15:12:13 <korzen> #link https://review.openstack.org/#/c/334381/2
15:12:37 <korzen> when the shared subnet was queried, it returned none
15:12:53 <ihrachys> aha. basically using full  common_db_mixin machinery for get_object() too. I think jlibosva was suggesting that before.
15:13:08 <ihrachys> without the whole machinery, query hooks are not applied for get_object
15:13:14 <korzen> because the sql query was construct to filter by NetworkRBAC.id not subnets.id
15:13:39 <ihrachys> that one makes sense too :)
15:13:59 <ihrachys> great work.
15:14:08 <korzen> I hace still some issue with extending the subnet dictionary
15:14:09 <ihrachys> korzen: you seem on a coding spree ;)
15:14:40 <korzen> so there may be some more difficulties ahead
15:14:57 <ihrachys> sure. but that's already a huge progress.
15:15:03 <ihrachys> do you have CI results with those included?
15:15:12 <korzen> ihrachys, yea, the debugger and I are the best friends now
15:15:14 <ihrachys> I mean, both issues fixed + subnet adopted
15:16:07 <korzen> ihrachys, ?
15:16:42 <ihrachys> korzen: do you have a patch that would validate those two fixes + subnet object used in db code in gate?
15:16:59 <ihrachys> or are they all stacked?
15:17:19 <korzen> ihrachys, yes, they are all stacked, the top is: https://review.openstack.org/#/c/321001/8
15:17:55 <ihrachys> ok great.
15:18:14 <korzen> and also some RBAC improvements for shared attr in subnet: https://review.openstack.org/#/c/331009/
15:18:42 <korzen> the subnet shared attr is special case, where shared is dependent on network shared state
15:19:16 <ihrachys> that last one seems like a bunch of fixes squashed into a single one
15:19:32 <korzen> so I have copied the code to valide the rbac_entries from db_plugin to rbac_db
15:20:33 <korzen> yes, the https://review.openstack.org/#/c/331009 is everything we need to change in subnet object to get it working with UT
15:20:35 <ihrachys> korzen: is it worth splitting the last one?
15:21:23 <korzen> it would probably be something more when I get a touch on functional and API tests
15:21:57 <ihrachys> korzen: but can't we test specific aspects of the change separately with our own targeted tests?
15:23:35 <korzen> what do you mean by our own targeted tests?
15:24:43 <ihrachys> korzen: the patch contains several changes (tenant-id logic, shared field logic, segment_id added, ...) can we have it all in separate pieces?
15:25:10 <korzen> ihrachys, yes, it can be split
15:25:14 <ihrachys> korzen: if the problem is that no tests trigger the issues right now, then let's trigger them specifically for each piece
15:25:25 <ihrachys> if needed, with new tests
15:25:58 <ihrachys> ok, let's better split then, because it's better for reading git history later, and reverts if we need any later
15:26:34 <korzen> ok, I will stack few more patches ;) it is already 5 in a row :)
15:26:50 <ihrachys> I understand the concern.
15:27:03 <sayalilunkad> with regards to https://review.openstack.org/#/c/284738 jlibosva suggested that we don't use update for the default security group stuff ..rather we just use create and delete because is_default is not updatable from the api
15:27:09 <ihrachys> maybe depends-on is a better answer than stacking, at least for pieces that touch different parts of the code.
15:27:53 <korzen> ihrachys, that maybe an answet
15:27:56 <korzen> answer*
15:28:13 <rossella_s> ihrachys, +1
15:29:11 <ihrachys> sayalilunkad: interesting. I think if we don't need to update that, then indeed it may be easier to claim it for no update.
15:29:25 <jlibosva> https://review.openstack.org/#/c/284738/37/neutron/objects/port/extensions/securitygroups.py@55 <- this is where discussion with sayalilunkad happened :)
15:29:36 <ihrachys> jlibosva++ that seems like simplifying the deal.
15:29:43 <ihrachys> what others think?
15:29:45 <sayalilunkad> ihrachys: yup
15:31:01 <jlibosva> so correct me if I'm wrong - but is_default is not even exposed to API, it's just internal logic of object to distinguish between default and ordinary SG. While ordinary SG just re-uses/encapsulates capabilities of DefautlSG object
15:31:20 <ihrachys> jlibosva: it's exposed in API, but read only.
15:31:54 <rossella_s> if nobody can write it then we don't need to handle updates
15:32:14 <ihrachys> oh wait. seems like not, it's not actually exposed.
15:32:28 <jlibosva> if it is, I can't find where :)
15:32:49 <ihrachys> yeah, I mixed things (name vs the attribute)
15:33:54 <ihrachys> anyhow, I think it's a good idea to get rid of the code. sayalilunkad, please follow the jlibosva suggestion :)
15:34:08 <sayalilunkad> ihrachys: cool, thanks
15:35:06 <jlibosva> sayalilunkad: ihrachys now the question is whether we want to expose it as a field or just an attribute of SG object
15:35:17 <jlibosva> but we can discuss on the gerrit :)
15:35:57 <ihrachys> jlibosva: not sure I follow the merits of both approaches, so yes, let's follow up on gerrit
15:36:13 <ihrachys> also, one thing that I want to revive this week is ports object patches. unless rossella_s wants to get back to it herself.
15:36:41 <ihrachys> afair we have a TODO list in the patch commit message, so hopefully I should be ready to proceed.
15:36:44 <sayalilunkad> jlibosva: ihrachys sure
15:36:47 <jlibosva> I can take over some patches
15:37:01 <rossella_s> ihrachys, I wish but I don't think I will have enough time
15:37:25 <ihrachys> jlibosva: port? :D I think that's the most critical piece right now.
15:37:28 <rossella_s> ihrachys, it would be great if you could take over
15:38:35 <ihrachys> jlibosva: but first thing, I guess we need to pay huge attention to what korzen already has on review to unblock his subnet endevour
15:39:12 <jlibosva> sure, just sayin' I'm slackin' on objects front :)
15:39:43 <korzen> ihrachys, jlibosva it would be nice to get a help in side patches ;)
15:39:59 <korzen> especially in those which are blocking also the port
15:40:17 <korzen> sorting and loading synthetic fields
15:40:18 <ihrachys> korzen: those in your queue? or you mean some other patches?
15:40:47 <ihrachys> korzen: yeah, yours. jlibosva, how about cooperating with korzen on splitting the bulk patch he has into reviewable pieces?
15:41:02 <jlibosva> korzen: I left some comments on load_synthetic this morning, but I forgot to send, so you have them in PS1 :)
15:41:11 <jlibosva> ihrachys: korzen sounds good
15:41:21 <ihrachys> jlibosva: korzen: thanks!
15:41:21 <korzen> jlibosva, and seen them, thanks :)
15:42:03 <korzen> I will work on the last UT to solve for Subnet
15:42:16 <korzen> it is the dictionary extension
15:43:01 <ihrachys> #topic Other patches on review
15:43:06 <korzen> neutron.tests.unit.plugins.ml2.test_extension_driver_api.DBExtensionDriverTestCase.test_subnet_attr
15:43:23 <ihrachys> I am not aware of any patches that are not objects related that would require team attention
15:43:41 <ihrachys> #topic Open discussion
15:43:58 <ihrachys> there are two things on the agenda from korzen, but seems like we covered those in objects section
15:44:08 <korzen> ihrachys, yest
15:44:24 <korzen> yes, exactly
15:44:46 <ihrachys> then we should probably be good to close the meeting, unless people have other topics to discuss. I give 2 minutes to raise anything. :)
15:45:04 <rossella_s> I have nothing else :)
15:46:21 <ihrachys> ok, then we close! :)
15:46:23 <ihrachys> #endmeeting