15:01:12 <ihrachys> #startmeeting neutron_upgrades
15:01:13 <openstack> Meeting started Mon Sep  5 15:01:12 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:13 <ihrachys> hey all
15:01:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:17 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:22 <electrocucaracha> o/
15:01:25 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:01:40 <asingh> Hi
15:02:05 <ihrachys> korzen is on PTO
15:02:12 <ihrachys> rossella_s is probably back? :)
15:02:47 <electrocucaracha> and it's holiday in US
15:03:02 <ihrachys> oh right, though some of US folks are still here :)
15:03:06 <ihrachys> we'll run it quick
15:03:12 <ihrachys> #topic Announcements
15:03:16 <ihrachys> we are in deep freeze mode
15:03:22 <ihrachys> milestone3 is cut-off
15:03:40 <ihrachys> we are waiting for rc1 to happen, when stable/newton branches will be created
15:03:47 <ihrachys> at which point ocata development will be open
15:03:57 <ihrachys> it will happen ~2 weeks from now
15:04:12 <ihrachys> in the meantime, we are blocked on landing anything not critical
15:04:30 <ihrachys> and btw seems like push-notifications don't really happen, so network and port objects don't land in Newton.
15:04:35 <ihrachys> which is not big deal from our side.
15:04:42 <ihrachys> #topic Partial Multinode Grenade
15:05:04 <ihrachys> I guess the last week it was mostly me to talk to jschwarz on our next steps for linuxbridge grenade job
15:05:12 <ihrachys> it did not really happen for multiple reasons.
15:05:18 <ihrachys> it's still on my plate though
15:05:42 <rossella_s> ihrachys, hi there, sorry for being late
15:05:45 <ihrachys> so no real updates in this regard so far.
15:05:48 <electrocucaracha> is it considered critical for m3?
15:05:50 * ihrachys waves at rossella_s
15:05:59 <ihrachys> electrocucaracha: what? linuxbridge job? no
15:06:09 <electrocucaracha> yeah, that one
15:06:12 <electrocucaracha> ok
15:06:18 <ihrachys> electrocucaracha: btw m3 happened, we are now looking for rc1 cut-off
15:06:28 <ihrachys> #topic Object implementation
15:06:42 <ihrachys> ok, for that one, we have two bits to consider for N inclusion
15:06:55 <ihrachys> one is from electrocucaracha to not raise on unknown filter passed from API layer
15:07:12 <ihrachys> #link https://review.openstack.org/#/c/365659/
15:07:28 <ihrachys> for anyone with review cycles, please take a look, it should go in N so that we don't regress
15:07:52 <ihrachys> another one is passing db model to dict extensions
15:07:54 <ihrachys> #link https://review.openstack.org/#/c/348279/
15:08:12 <ihrachys> I am still working on that one, needs some refactoring for tests code to pass gate
15:08:22 <ihrachys> those are two bits known to me critical for N
15:08:30 <ihrachys> other than that, we are looking into Ocata now
15:08:31 <electrocucaracha> regarding unknown filters, adding UT for API for now the API uses models, so
15:08:59 <ihrachys> electrocucaracha: what do you mean api uses models?
15:09:21 <electrocucaracha> yes, I was checking the code and it uses the plugins to get_objects method
15:09:55 <ihrachys> electrocucaracha: you mean db/api.py file?
15:10:12 <ihrachys> electrocucaracha: I am not sure how it's affected because filter validation is isolated in base class get_objects
15:10:58 <electrocucaracha> let me find the current reference where it discards the unknown filters
15:12:37 <dasanind_> o/
15:13:07 <electrocucaracha> I wasn't prepare to share it, ihrachys continue with the meeting in the meantime I will try to find it
15:13:15 <ihrachys> electrocucaracha: ok
15:13:23 <ihrachys> so, we are looking into Ocata now.
15:13:35 <ihrachys> we will get back to existing patches once the branch is open
15:13:51 <ihrachys> in the meantime, we can keep existing patches in good shape to merge
15:14:02 <ihrachys> I don't have any specifics to share right now.
15:14:14 <ihrachys> I've heard that some folks had questions on some patches
15:14:23 <ihrachys> it would probably be a good time to share and discuss those
15:15:40 <ihrachys> electrocucaracha: you mentioned something to discuss today
15:15:56 <electrocucaracha> yes, about outer joins that asingh has been faced
15:16:13 <electrocucaracha> this is an example of that https://github.com/openstack/neutron/blob/a6e1cd4e80145cfe5ac909f7cf86fb0399ac58fe/neutron/db/l3_hascheduler_db.py#L64
15:16:33 <electrocucaracha> basically, what is the plan for those cases?
15:16:34 <asingh> Ihrachys  during object integration there are joins and outer join , neutron/objects.base.py does don't have method definition for them
15:16:49 <ihrachys> ok I see
15:17:05 <ihrachys> I think the first step would be isolating those pieces under object definitions
15:17:15 <ihrachys> so you would have some object specific functions that do the job
15:17:25 <ihrachys> you basically just move the code closer to objects
15:17:40 <ihrachys> then later when we see common patterns, we could think of how to generalize
15:18:04 <ihrachys> does it make sense? I don't want to block the progress there while we try to generalize
15:19:31 <electrocucaracha> yes, but I guess that it will be good idea to list the dependencies of the objects
15:19:33 <asingh> Ihrachys Do you mean break join queries using existing methods for object integration ?
15:20:21 <ihrachys> electrocucaracha: yeah, that would make sense. though it would probably be a tad easier to detect if all db accessing code is under neutron/objects/ anyway.
15:21:12 <ihrachys> asingh: I mean, if you struggle to come up with how to implement something with existing objects api then move the custom code like that function doing the join into the corresponding object (Agent?) and keep it there exposed as a function on the object class.
15:22:29 <electrocucaracha> well, I was thinking that outers are more like filters on the object that you depend on
15:23:05 <ihrachys> electrocucaracha: yeah, I guess. so you suggest it could be implemented as a custom filter?
15:24:42 <ihrachys> even if that's the case, I would suggest to parallelize the efforts
15:24:50 <electrocucaracha> I was thinking loudly, that given outer joins retrieves the information that doesn't meet with the criteria maybe those can be implemented in that way
15:25:04 <ihrachys> one would be isolating db access code into an object, another being a better advanced api for objects.
15:25:42 <ihrachys> when we move the code into the object, we can leave a NOTE/TODO to get back to it later
15:25:54 <electrocucaracha> +1
15:26:19 <ihrachys> ok I hope it clarifies the path forward.
15:26:20 <asingh> +1
15:26:31 <ihrachys> electrocucaracha: you mentioned other concerns I guess?..
15:26:55 <dasanind_> ihrachys: electrocucaracha: so we do not refactor outer joins just move the code?
15:27:06 <electrocucaracha> yes, the other one is cases where the method receives a session instead of context
15:27:19 <ihrachys> dasanind_: as a first step, yes. later we can follow up with a better suggestion assuming there is one
15:27:33 <ihrachys> custom filters look like a path to consider
15:27:54 <ihrachys> electrocucaracha: yeah, that one, I think it's generally ok to refactor to pass context instead of a session
15:27:56 <electrocucaracha> this is an example of that https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb31317ba469a58/neutron/ipam/drivers/neutrondb_ipam/db_api.py#L29
15:28:13 <ihrachys> electrocucaracha: we need to be mindful that some bits may be part of some public plugin api
15:28:23 <ihrachys> in which case we may not be able to replace it right away.
15:28:27 <dasanind_> ihrachys: thanks
15:28:49 <ihrachys> but we'll take a look at it case by case I guess
15:29:04 <electrocucaracha> one suggestion was identify the callers of that method and change the way that they're consuming that method, but yeah we can break something there
15:29:34 <ihrachys> electrocucaracha: we will need to work closely with folks from affected subteams.
15:29:56 <ihrachys> electrocucaracha: like in this case, ipam/l3 folks would be the right fellows to ask about the status of the class
15:30:06 <electrocucaracha> ihrachys: so that raises and other question, how can we identify them?
15:30:21 <electrocucaracha> ihrachys: ok, based on the code that we're touching
15:30:32 <ihrachys> electrocucaracha: I don't think you can until you try to integrate
15:30:45 <ihrachys> right, touch and see where it leads
15:31:01 <ihrachys> we don't want to go and change it across the board even where not really needed ;)
15:31:50 <electrocucaracha> or at least understand the needs for having implemented in that way
15:32:20 <ihrachys> ok any more questions on ovo implementation?
15:32:41 <electrocucaracha> well, I found the reference of the filters
15:33:03 <ihrachys> electrocucaracha: shoot
15:33:08 <electrocucaracha> basically, this is the place where the filters are taken based on the columns
15:33:08 <electrocucaracha> https://github.com/openstack/neutron/blob/master/neutron/db/common_db_mixin.py#L209
15:33:54 <ihrachys> electrocucaracha: ok. how is your patch affected there?
15:34:12 <ihrachys> electrocucaracha: afaiu you just disable validation in the object middleware
15:34:39 <electrocucaracha> ihrachys: yes, for now it only have a condition for that
15:34:44 <ihrachys> electrocucaracha: so that's what you would probably check - that if the validation is disabled, calling it with unknown filters does not raise an error but pass the filters thru
15:34:51 <electrocucaracha> ihrachys: which looks to simple to be truth https://review.openstack.org/#/c/365659/1/neutron/objects/base.py@412
15:35:12 <ihrachys> haha. don't be afraid of simplicity ;)
15:35:26 <ihrachys> that's actually the gist what I envisioned for the patch (plus tests)
15:35:58 <electrocucaracha> yeah, but finding simplicity in openstack is rare
15:36:30 <ihrachys> :) ok I assume you have the path forward for the patch then. I will review it in due course.
15:36:46 <electrocucaracha> ihrachys: thanks
15:37:01 <ihrachys> ok I assume we can move on but feel free to raise more stuff later in the meeting
15:37:03 <ihrachys> #topic Other patches on review
15:37:17 <ihrachys> I don't know of any upgrades related patches that are not ovo lately
15:37:43 <ihrachys> #topic Open discussion
15:38:03 <electrocucaracha> relocation patches are going to be on hold until ocata development?
15:38:14 <ihrachys> electrocucaracha: yes, that's now given
15:38:35 <ihrachys> electrocucaracha: nothing goes in now unless it has FFE (meaning, it was targeted and got exception)
15:38:44 <ihrachys> electrocucaracha: plus bug fixes obviously, but that's not our case
15:39:05 <electrocucaracha> ihrachys: agree
15:39:25 <ihrachys> ok, I guess we can call it a day?
15:39:35 <electrocucaracha> so, rebase them or solving merge conflicts is not super urgent for now
15:39:41 <ihrachys> electrocucaracha: yea
15:39:56 <ihrachys> but they are better to be ready when we open the branch
15:40:12 <ihrachys> I may have another run thru them later this week
15:40:15 <ihrachys> just to make sure it's all in shape
15:40:33 <ihrachys> ok, let's use remaining 20 mins to do some coding and reviews
15:40:34 <electrocucaracha> got it
15:40:42 <ihrachys> thanks everyone for joining
15:40:42 <ihrachys> #endmeeting