15:01:17 <ihrachys> #startmeeting neutron_upgrades
15:01:18 <openstack> Meeting started Mon Aug 15 15:01:17 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:22 <ihrachys> hi all.
15:01:23 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:27 <electrocucaracha> Hey
15:01:29 <ihrachys> let's grasp who's with us today
15:01:31 <ankur-gupta-f> hi Ihar
15:01:41 <ihrachys> rossella_s and korzen are having some holiday
15:02:07 * electrocucaracha is in the airport
15:02:32 <ihrachys> are we three?
15:02:50 * ihrachys waits some more for more folks to pop up
15:02:51 <asingh> hey
15:02:53 <ankur-gupta-f> we also have newcomers Shashank, Nakul, Aradhana, Sindhu as well
15:03:05 <ihrachys> jschwarz:
15:03:06 <sindhu> Hi ihrachys
15:03:34 <sshank> Hi Ihar. This is Shashank.
15:03:41 <ihrachys> hi all
15:03:50 <ihrachys> ok, let's run the meeting, probably a shorter one
15:03:52 <ndahiwade> Hi All, Nakul here
15:03:56 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:04:36 <ihrachys> #topic Announcements
15:04:51 <ihrachys> I have nothing specific, just a usual note that we are approaching N-3 (end of this month)
15:04:55 <manjeets_> 0/
15:05:12 <ankur-gupta-f> ihrachys: goal is to have P1 by N-3 correct
15:05:21 <ihrachys> also, some of us will be on the midcycle meetup that starts tomorrow, and will cover upgrade questions
15:05:33 <ihrachys> ankur-gupta-f: P1 as in ports/networks/subnets? more or less yes
15:05:45 <ihrachys> ankur-gupta-f: but we are free to land more, it's ongoing work
15:05:53 <manjeets_> ihrachys, would that be possible to attend that midcycle virtually ?
15:06:23 <ihrachys> manjeets_: I think other folks were raising the question on a previous neutron team meeting
15:06:35 <ihrachys> I think it was Sukhdev, but I remember HenryG was there too
15:06:49 <ihrachys> HenryG: do we have online participation option for the midcycle?
15:08:22 <sindhu> In the last meeting, someone shared this: https://wiki.openstack.org/wiki/Infrastructure/Conferencing
15:08:40 <sindhu> I don't know if this works
15:08:58 <ihrachys> ok, I guess we would need to follow up with HenryG ofline.
15:09:15 <ihrachys> sindhu: yeah, it's not just infrastructure; someone should actually know how to run it.
15:09:43 <manjeets_> ok, ihrachys looks like port ovo (introduction) is close
15:09:47 <ihrachys> we will try to keep people updated via emails and irc anyway.
15:10:03 <ihrachys> manjeets_: actually, I believe both are, for the specific needs that push-notifications have for us
15:10:19 <manjeets_> and I have a question how we gonna deal with joins ?
15:10:22 <ihrachys> manjeets_: because some things are not really interesting to agents, like tags
15:10:29 <ihrachys> or whether rbac works
15:11:18 <ihrachys> so I dropped most of crust that is not in scope for P1 out of networks object. The result is: https://review.openstack.org/#/c/269658/
15:11:31 <ihrachys> but let's get to it later :)
15:11:52 <ihrachys> #action manjeets_ to follow up with HenryG on teleconferencing option for midcycle
15:12:05 <ihrachys> #topic Partial Multinode Grenade
15:12:36 <ihrachys> I don't think much changed in this regards, we are still waiting for needed devstack patches to land to proceed with linuxbridge job
15:13:07 <ihrachys> specifically, we wait for https://review.openstack.org/#/c/346282/ and https://review.openstack.org/#/c/345707/
15:13:38 <ihrachys> we probably need someone like sc68cal to get back to those
15:14:18 <ihrachys> ok, let's move on
15:14:20 <ihrachys> #topic Object implementation
15:14:46 <ihrachys> so for objects, indeed we focus on delivering object definitions for subnets/networks/secgroups/ports for push-notifications feature
15:14:53 <ihrachys> subnets are in tree, same for secgroups I think
15:15:09 <ihrachys> networks: https://review.openstack.org/#/c/269658/ and ports: https://review.openstack.org/#/c/351368/
15:15:15 <manjeets_> is security group implementation complete ?
15:15:34 <ihrachys> manjeets_: definitions, yes: https://review.openstack.org/#/c/351101/
15:15:38 <manjeets_> I thought its just object for sg but integration is pending
15:15:42 <ihrachys> it's not integrated into db code
15:15:52 <manjeets_> ok
15:15:56 <ihrachys> yes, what we focus on for push-notifications, it's all about definitions
15:16:17 <ihrachys> people interested in adoption patches should rebase those pieces on what we have for definitions, and proceed the work as stacked
15:16:31 <ihrachys> I hope we land ports and networks patches in due course
15:17:27 <ihrachys> while some of us work on delivering that, others work on preparing tree for more objects
15:17:53 <ihrachys> there are two pieces there: rearranging the objects subtree as per discussion in https://review.openstack.org/#/c/352577/
15:18:07 <ihrachys> ankur-gupta-f: I think we want to make decision on that one and respin if needed
15:18:24 <ankur-gupta-f> agreed
15:18:35 <ankur-gupta-f> I am still for moving all objects and extensions into their own directory
15:18:44 <ihrachys> there are two options to go: one is to put all extension objects into the module that contains corresponding core resource
15:18:47 <ankur-gupta-f> keep only base and the README in the root
15:19:07 <ihrachys> another one is keeping each piece split (port security separate from port separate from allowed address pairs)
15:19:23 <manjeets_> ihrachys, I guess we can get that patch ready and start following design from beginning for rest of objects
15:19:51 <ihrachys> manjeets_: right. plus reshuffle existing ones when we can do it without breaking others' work
15:19:56 <manjeets_> I mean dir structure because refactors are always tricky
15:20:25 <ankur-gupta-f> ihrachys: base common_types README and init should be the only files in the root dir
15:20:52 <ihrachys> what is the benefit of split?
15:21:21 <ihrachys> I find that most of the times when I do a change to e.g. AllowedAddressPair, I need to do corresponding changes to Port
15:22:05 <ihrachys> and keeping both in a single module helps me to walk thru all the relevant code instead of browsing a directory.
15:22:07 <electrocucaracha> I was thinking that could be useful during development phaae
15:22:23 <ihrachys> electrocucaracha: that - which option
15:22:31 <ankur-gupta-f> Well for 1. Splitting and keeping object definitions and files separate would be easier for development because it would lead to less merge conflicts
15:22:46 <ankur-gupta-f> since so many of us are touching the same files
15:23:32 <ankur-gupta-f> I saw a patch with 4 object definitions in the same file. Combining all of it into one file does no benefit. It just means if anyone else needs to touch it, it will cause complications
15:24:08 <ankur-gupta-f> specifically https://review.openstack.org/#/c/338625/4/neutron/objects/quota.py
15:24:13 <ihrachys> ankur-gupta-f: I think the only real benefit in terms of git conflicts is when it comes to changes to import sections
15:25:01 <ankur-gupta-f> So hold off on splits for now? But we still should enforce a specific dir organization/tree
15:25:41 <ihrachys> ankur-gupta-f: well, the file you referred to, it's actually a neat one, because I have all relevant definitions in a single file, so I can grasp what's available to me for quotas.
15:26:02 <ihrachys> ankur-gupta-f: I personally find java style of putting each class in a separate file despicable. but maybe it's just me.
15:26:17 <ankur-gupta-f> haha. Maybe thats my Java history coming in..
15:26:24 <ihrachys> ankur-gupta-f: at least I believe whatever is chosen, we should keep consistency with arrangement of models in neutron/db/models
15:27:03 * manjeets_ is not a java fan
15:27:08 <electrocucaracha> +1
15:27:16 <ankur-gupta-f> ihrachys: so what is the final verdict?
15:27:17 <ihrachys> btw I think we landed it, sec, searching for the patch for model tree structure
15:27:39 <ihrachys> that one: https://review.openstack.org/#/c/351438/
15:27:58 <ankur-gupta-f> right.
15:28:17 <ihrachys> so it says "We have decided to move all models definitions to neutron/db/models/ with no futher nesting after that point" whatever it means
15:28:31 <ihrachys> it may be interpreted like each model going into a separate file too
15:28:57 <electrocucaracha> Without subfolders?
15:28:57 <manjeets_> may be i'll add a note in that to categorize
15:28:59 <ankur-gupta-f> right so there wouldn't be neutron/db/models/network neutron/db/models/subnet
15:29:01 <ihrachys> but since models are interrelvated (like ip allocation referring to a port, and port referring to a binding), it may be not ideal
15:29:31 <ihrachys> ankur-gupta-f: right. my reading of that was that we will have neutron/db/models/port.py and neutron/db/models/network.py
15:29:32 * electrocucaracha is departing
15:29:51 <ihrachys> but then, it does not answer whether allowed address pairs have their own file, or put into port.py one
15:29:52 <ankur-gupta-f> ihrachys: So lets enforce the nested structure for objects, but not worry about the splitting.
15:30:12 <ihrachys> ankur-gupta-f: like neutron/objects/port/port.py containing everything?
15:30:25 <manjeets_> ihrachys, do we need to move models in db/models_v2 ??
15:30:32 <ihrachys> ankur-gupta-f: give an example, it may help
15:30:37 <ihrachys> manjeets_: I think so, yes
15:30:40 <ihrachys> manjeets_: eventually
15:30:58 <ankur-gupta-f> ihrachys: objects/network for one. Like listed in the README in that patch that is in question
15:31:04 <manjeets_> i think they are better as they are now but to have centralized structure we may end up doing that
15:31:22 <ankur-gupta-f> the base network.py file is in /objects/network/, but all the network extensions are in objects/network/extensions
15:32:13 <ankur-gupta-f> objects/subnet/ would contain subnet.py and subnetpools.py
15:32:45 <ihrachys> ankur-gupta-f: subnetpools are first order resources
15:33:01 <ihrachys> I think they are loosely related to subnets
15:33:52 <ankur-gupta-f> well then... :|
15:33:59 <ihrachys> ankur-gupta-f: so the point is, from objects perspective, there are no extensions, they are strictly defined as containing whatever extensions may add to core resources
15:34:17 <ihrachys> ankur-gupta-f: f.e. we don't have a port object without a security group
15:34:30 <ihrachys> such a port is merely a port object with secgroup_id = None
15:34:35 <ihrachys> same for other extensions
15:35:06 <ankur-gupta-f> okay. Lets leave for now then until we have a better picture once the P1 objects land
15:35:37 <ihrachys> ankur-gupta-f: ok. let's think on it a bit more and follow up in gerrit.
15:35:58 <ihrachys> I noticed a lot of patches that move models around.
15:36:03 <ihrachys> first thanks for that everyone!
15:36:19 <ihrachys> second, we need to land them tactically not to piss off others with git conflicts
15:36:23 <manjeets_> yea too many conflicts on them now
15:36:41 <ihrachys> once we will land P1 bits I will get back to those to see what we can land more or less safely
15:36:58 <ankur-gupta-f> ihrachys: +1.
15:37:40 <manjeets_> ok l3 is always hot thing
15:37:49 <manjeets_> it will always have conflicts
15:37:56 <ankur-gupta-f> ihrachys: our team will be taking on lots of p2 and other objects and models in the next month of so. But P1 models and objects should be priority to merge before the rest
15:37:56 <ihrachys> now that we have a high number of new contributors, we may need to rethink how we track things.
15:38:02 <ihrachys> I for one feel like a bottleneck at times
15:38:27 <ihrachys> you probably noticed that I am not that responsive these days :)
15:38:44 <ihrachys> I noticed electrocucaracha prepared a nice google doc to track ovo progress: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101580.html
15:38:56 <ihrachys> #link https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112
15:39:07 <ihrachys> I think the format is worthy
15:39:17 <ihrachys> that should help us to understand where we stand
15:39:19 <ankur-gupta-f> Yes, much better than the Etherpad haha
15:40:05 <ihrachys> I would really love if some of coordination work could be taken by someone in the team, maybe someone from the new folks
15:40:20 <ankur-gupta-f> ihrachys: what are your thoughts on also adding review URLs to that doc
15:40:31 <ankur-gupta-f> electrocucaracha: is coordinating all the newcomers on our side
15:40:50 <ihrachys> for one, it would be cool to see someone spearheading and monitoring model moves, getting them in shape and then reaching out those with core permissions when it's ready.
15:41:03 <ihrachys> ankur-gupta-f: I think it's good to add review links, yes.
15:41:17 <manjeets_> ihrachys, I can do a initial review on those model moves
15:41:18 <ihrachys> ankur-gupta-f: yeah, I was thinking electrocucaracha could help with coordination.
15:42:03 <ihrachys> manjeets_: great. an initial review would be of much help. we should specifically look at whether what's proposed reflects the README that we landed, and whether deprecation is handled as expected.
15:42:04 <ankur-gupta-f> ihrachys: done. Thanks Victor for volunteering to spearhead the models effort
15:42:23 <manjeets_> yea thats what i'll make sure first
15:42:24 <ihrachys> ankur-gupta-f: not sure he volunteered, but yeah, he has no choice lol
15:42:37 <dasm> ihrachys: ++
15:42:39 <dasm> :D
15:42:56 <ihrachys> manjeets_: once you have identified bits that we can land, reach out me and others so that we can fast track
15:43:05 <manjeets_> sure
15:43:09 <ihrachys> manjeets_: thanks a lot for taking on the challenge :)
15:43:52 <ankur-gupta-f> sindhu: dasanind: sshank: ndahiwade: please add your Gerrit URLs to the models/creation/integration patches you have up to the Google Doc. in a clean manner "In Progress(sindhu) -- http://blahblahblah/#1231231"
15:44:22 <ihrachys> with P1 work ongoing, we should not forget about database adoption patches. after the midcycle, I will get back to setting inventory list so to speak of what we already have, to see where to proceed next.
15:44:32 <manjeets_> keep ovo and model patches (links) separately organized
15:44:48 <ihrachys> we may want to identify more independent 'tracks' in the process and find more willing folks to help with coordination.
15:45:13 <manjeets_> i have port dns and network dns ready which mlavalle will be doing end to end testing
15:45:27 <ihrachys> for one, there is a separate topic of database adoption code; there is api layer work that jschwarz started to capture in some patches; there is probably more.
15:46:12 <ankur-gupta-f> along the coordination line, is the Open Discussion Topic I brought up about Commit Messages and Names
15:46:13 <ihrachys> manjeets_: cool! you may need to rebase the patch onto port patch I have because I 'stole' the object from you so there will be conflicts later on.
15:46:44 <manjeets_> I am waiting for your patch to get in It will be quick rebasing afterwards
15:46:57 <ihrachys> ankur-gupta-f: ok, what's the proposal?
15:47:10 <ankur-gupta-f> So right now the Commit Messages are a little scattered
15:47:14 <ankur-gupta-f> Discuss about certain format for Commit Message to avoid potential  overlapping work, like: "Introduce OVO *item*; Refactor *item* DB Model
15:47:42 <ankur-gupta-f> So
15:47:44 <ankur-gupta-f> i.e.
15:47:48 <ankur-gupta-f> for Subnet
15:48:07 <manjeets_> i think the messages are already clear
15:48:10 <manjeets_> ankur-gupta-f,
15:48:19 <ankur-gupta-f> "Introduce OVO Subnet" "Refactor Subnet DB Model" "Integrate Subnet Object"
15:48:30 <manjeets_> its relocate *** db  model
15:48:32 <ihrachys> ok. I find topics a better mechanism to track patches of the same 'track', but if folks feel that commit message consistency would help, I am fine with setting rules.
15:48:34 <manjeets_> as HenryG suggested
15:48:40 <ihrachys> ankur-gupta-f: it should be 'relocate' not 'refactor'
15:48:45 <ihrachys> ouch what manjeets_ said :)
15:48:55 <ankur-gupta-f> yea relocate
15:49:12 <manjeets_> all relocate patches have topic of bug (let me get the link in a moment)
15:49:15 <ankur-gupta-f> I bring it up because prior to the doc our newbies picked up objects
15:49:22 <ankur-gupta-f> then realized someone had already done them
15:49:29 <ankur-gupta-f> but under a poor commit message
15:49:34 <ankur-gupta-f> and not attached to topic or the bug
15:49:44 <manjeets_> bug/1597913
15:50:00 <ihrachys> right, https://review.openstack.org/#/q/topic:bug/1597913
15:50:03 <ankur-gupta-f> Also when searching on gerrit. It will be easier to parse through the all the patches if there is a common commit message
15:50:17 <ihrachys> I generally agree that consistency should be in place
15:50:40 <ihrachys> let's just apply it naturally, not immediately going thru the list and modify everything.
15:50:41 <ankur-gupta-f> https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db
15:50:46 <ihrachys> I believe folks should catch up
15:51:07 <ankur-gupta-f> So we in agreement then. Consistent Commit messages
15:51:12 <ihrachys> but as for tracking matters, topics are very important, we should set them if they are not in place.
15:51:49 <sindhu> Also, should the object creation and integration be in the same patch?
15:51:51 <ihrachys> ankur-gupta-f: I think yes, I just prefer 'should' instead of 'must' when it comes to commit messages. I don't want to -1 due to that, but suggestion? yeah, why not.
15:52:03 <ihrachys> fyi I try to keep the following format for introduction patches "Introduce ovo objects for ports"
15:52:07 <manjeets_> sindhu, it can be separated if objects is complicated
15:52:32 <ihrachys> sindhu: in long term and ideally, it should go together, but tactically, we may change it.
15:52:59 <ihrachys> sindhu: what manjeets_ said, if they are themselves a significant piece of work, or when we need to land them earlier, like in case of push-notifications right now
15:53:48 <ihrachys> ok, one thing that is not exactly OVO that I wanted to mention
15:54:03 <ihrachys> jschwarz is working on some patches that should solve some integration issues for objects.
15:54:16 <manjeets_> ok object db api ?
15:54:24 <ihrachys> specifically, when it comes to unknown filters being passed from api layer into plugins: https://review.openstack.org/#/c/352809/
15:54:29 <sindhu> Cool ... thank you :) manjeets_ ihrachys
15:54:47 <ihrachys> as well as when it comes to plugins returning unknown attributes: https://review.openstack.org/#/c/354046/
15:55:09 <ihrachys> (the last one, like in case of object.to_dict() result directly returned irrespective of enabled extensions)
15:55:26 <ihrachys> so, reviews are welcome
15:55:56 <ihrachys> I may need to talk it through with other neutron team members on the midcycle because it seems there are some concerns, at least from armax
15:56:46 <ihrachys> #topic Open discussion
15:57:00 <ihrachys> I skipped 'other patches', but you can raise anything here if relevant
15:57:11 <ihrachys> anyone has a quick topic for 2 mins we have? :)
15:57:13 <manjeets_> ihrachys, mlavalle was saying network dns and port dns does not have tempest tests
15:57:39 <ihrachys> manjeets_: does that block us from objects work? or adoption?
15:57:40 <manjeets_> it could have been easy to test objects implementation if we had scenario test
15:57:44 <manjeets_> no
15:57:52 <manjeets_> ihrachys, it does not block
15:58:08 <manjeets_> I just added a scenario test for networkdns
15:58:14 <ihrachys> manjeets_: ack. well, not until we actually hook the object I spinned up into the db code anyway. :)
15:58:19 <ihrachys> manjeets_: cool! link?
15:58:46 <manjeets_> https://review.openstack.org/#/c/354447/
15:59:05 <manjeets_> but need to figure out how do I enable dns-integration extension driver by default
15:59:14 <manjeets_> thats the reason it failed over gate
15:59:28 <manjeets_> it passes when extension is enabled
15:59:37 <ihrachys> ok I will review it when I have time
15:59:43 <manjeets_> cool thanks ihrachys
15:59:48 <ihrachys> manjeets_: we have gate hooks in api gate
16:00:10 <ihrachys> you put what you need at https://github.com/openstack/neutron/tree/master/neutron/tests/contrib/hooks
16:00:20 <harlowja_at_home> ding :-P
16:00:23 <ihrachys> and then they are applied as in https://github.com/openstack/neutron/blob/master/neutron/tests/contrib/gate_hook.sh#L66
16:00:45 <ihrachys> sorry, we are out of time
16:00:45 <ihrachys> #endmeeting