15:00:23 <ihrachys> #startmeeting neutron_upgrades
15:00:32 <openstack> Meeting started Mon Sep 19 15:00:23 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:36 <openstack> The meeting name has been set to 'neutron_upgrades'
15:00:41 <ihrachys> o/
15:00:44 <korzen> hello
15:00:48 <electrocucaracha> o/
15:00:48 <sindhu> hello
15:00:55 <dasanind_> o/
15:01:23 <johndperkins> o/ hi
15:01:31 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:01:51 <ihrachys> #topic Announcements
15:02:13 <ihrachys> stable/newton is branched now, master is open for Ocata development
15:02:20 <rossella_s> hello
15:02:29 <ihrachys> we should be able to land more ovo related patches now
15:02:39 <electrocucaracha> yeah
15:03:02 <ihrachys> #topic Partial Multinode Grenade
15:03:38 <ihrachys> now that stable/newton is created and the 'old' side of the grenade job has all the needed linuxbridge fixes, we can restart work on -linuxbridge partial grenade job
15:04:10 <ihrachys> I will reach out to folks responsible for that part in next weeks
15:04:18 <korzen> is stable/newton set as lates stable in grenade now?
15:04:46 <ihrachys> korzen: well that's something to check actually. you think it's still mitaka? we may then need to wait for the switch to happen
15:05:06 <korzen> I've heard that is is still mitaka
15:05:07 <ihrachys> I honestly lack details about when grenade job switches to a newer stable branch, I thought (probably wrongly) it's automatic
15:05:15 <ihrachys> ok good to know :)
15:05:38 <ihrachys> #topic Object implementation
15:05:56 <ihrachys> now that master is open for Ocata, I want us to get model moving patches in quick
15:06:29 <ihrachys> I will check those this week, so if you think you have some patches of those that need more love and are not ready to land, please respin and polish
15:07:09 <ihrachys> once we move all models, the review focus will switch to actual objects. I noticed we have quite some, and some folks are kind enough to review those (thanks korzen!).
15:07:18 <electrocucaracha> I tried to rebase some of them(relocate patches) during the morning,
15:07:24 <ihrachys> electrocucaracha++
15:08:35 <korzen> I'm trying to rebase the network object but got stuck in UT rework
15:08:44 <ihrachys> atm I believe it's a matter of review attention to make progress in this topic, I will fulfil my part. hopefully second +2s won't wait.
15:08:47 <korzen> it is and nightmare
15:09:17 <ihrachys> korzen: if it takes too much of your time, you may upload a WIP and I can take a look at missing bits.
15:09:22 * dasm is late... o/
15:09:32 <ihrachys> electrocucaracha also noticed some issues with ports object today.
15:09:44 <electrocucaracha> korzen: is network depending on port ovo?
15:09:49 <korzen> yes
15:10:04 <korzen> it is kind of stacked
15:10:06 <ihrachys> electrocucaracha: I would like us to stick to procedure where we don't respin patches but add fixes on top, so that the author have a chance to look at the diff before applying it
15:10:38 <ihrachys> we had some wrong changes applied in the past (for db_obj patch), so it's better to check first
15:10:53 <ihrachys> reverting is sometimes not as easy.
15:11:59 <ihrachys> electrocucaracha: are we in agreement here?
15:12:10 <electrocucaracha> ihrachys: sure
15:12:15 <ihrachys> ok cool.
15:12:44 <korzen> UT framework for objects is getting more and more complicated, now if we have some exception that for example some object do not have relationship defined, it is screwing the tests
15:12:44 <ihrachys> people who worked on new objects lately, do you have any specific issues to raise here?
15:13:17 <ihrachys> korzen: yeah, I wanted to look at refactoring the test suite a bit, but I first wanted to land ports and networks not to introduce more mess
15:13:36 <korzen> network IS introducing real mess :)
15:13:40 <korzen> in UT
15:13:42 <ihrachys> korzen: some test cases may also use some details on failure.
15:14:14 <ndahiwade> korzen:https://review.openstack.org/#/c/370452/.Could you answer this?
15:15:17 <ihrachys> ndahiwade: what's the concern there? I think you identified the direction correctly.
15:15:33 <korzen> I guess you can cherry pick ontop on network patch
15:15:39 <ihrachys> ndahiwade: you should work on integrating it, and hopefully we land network object quick so that you can respin the patch to integrate it into the object too.
15:16:30 <dasanind_> ihrachys: Queries for the objects VXlan, Gre, Genevetype allocation/endpoints uses session there is no context in these functions. I am introducing context in the apis for these. Is that teh correct approach?
15:16:36 <ndahiwade> korzen:ihrachys:Okay thanks,should i wait for the Network patch merge conflicts to be resolved before cherry-picking?
15:16:57 <manjeets> o/
15:16:58 <korzen> ndahiwade, I will push the patch in a second
15:17:04 <ihrachys> dasanind_: generally yes, and I think we discussed that in one of prev meetings.
15:17:08 <ndahiwade> korzen:Thanks
15:17:21 <ihrachys> dasanind_: tl;dr as long as it's not a real public api, it should be fine to change signatures.
15:17:39 <sindhu> ihrachys: I used the context.get_admin_context()    https://review.openstack.org/#/c/368499/3/neutron/plugins/ml2/drivers/type_flat.py
15:17:41 <dasanind_> ihrachys: Thanks will do that then
15:18:36 <ihrachys> sindhu: I don't think THAT is correct
15:18:39 <sindhu> ihrachys: is it ok to do that?
15:18:49 <ihrachys> sindhu: we should not allow users to create any random objects as admin
15:19:26 <sindhu> ihrachys: hmm I knew it would be a problem. Will change that :) thank u
15:19:43 <ihrachys> sindhu: I would need to look at the code closely, but seems wrong. the question is, how would you pull in the current context from there?
15:20:44 <sindhu> ihrachys: Ah okay ... !!
15:21:43 <ihrachys> sindhu: that's a tough one, let's discuss details in the patch once I get to it
15:22:05 <sindhu> ihrachys: sure
15:22:23 <sshank> ihrachys, does test_filtering_by_fields() in test_base correctly handle list fields? I had to add a condition to make the unit test pass here: https://review.openstack.org/#/c/356766/22/neutron/tests/unit/objects/test_base.py@1226
15:22:59 <ihrachys> sshank: it's not. I already have that kind of change in some other patch :) we probably should have landed it separately.
15:23:01 <korzen> sshank, yes, it is correct
15:23:20 <ihrachys> sshank: but for now it's fine you maintain it locally
15:23:26 <korzen> sshank, I mean that this is correct approach but it is also included in other patch
15:23:42 <sshank> Okay. I can rebase once the other gets merged.
15:24:19 <ihrachys> #topic Other patches on review
15:24:24 <manjeets> since master is open for c-1 would relocation patches now be accepted ?
15:24:31 <korzen> when talking about filtering by fields, I'm getting error when trying to filter by synthetic field 'segments' for network object
15:24:56 <korzen> it seems like segments are now generated in UT by default
15:25:08 <korzen> so it is populated in db_objs
15:25:27 <ihrachys> korzen: you think we will be able to solve it in this audience? :)
15:25:33 <ihrachys> manjeets: yes, we discussed that above
15:25:43 <ihrachys> korzen: I mean not the audience but venue
15:26:19 <korzen> I'm just asking, maybe someone had idea why it is now happening ;)
15:26:46 <ihrachys> ok, not me
15:27:25 <korzen> ok, I will push the code with workarounds
15:27:44 <ihrachys> yeap. once it's up and we see how it fails, I may give more reasonable suggestions ;)
15:27:48 <electrocucaracha> korzen: lemme now when you have that ready to take a look
15:28:06 <ndahiwade> korzen:I was facing the same error in NetworkDhcpAgentBinding UT for dhcpagent as synthetic fields
15:28:07 <manjeets> korzen I am issues with type of synthetic fields type
15:28:36 <manjeets> for quotas
15:29:05 <ihrachys> ok, so re topic, I don't have any upgrade specific patches in the queue.
15:29:26 <ihrachys> we probably need to spin up a patch that forbids contract migrations this cycle
15:29:30 <manjeets> when i create object it shows field type as list but when i do get_object its show <?>
15:29:39 <ihrachys> as per the plan tentatively set in Cork
15:29:41 <electrocucaracha> ihrachys: do we have some priorities for ocata release as we have for newton?
15:29:56 <ihrachys> electrocucaracha: yes?.. switching the whole code to OVO :)
15:30:13 <ihrachys> electrocucaracha: + making it possible to evolve the db without --contract
15:30:14 <electrocucaracha> ihrachys: so basically, it's as much as we can hehehe
15:30:22 <ihrachys> electrocucaracha: you grasp the idea
15:30:36 * electrocucaracha challenge accepted
15:30:41 <ndahiwade> manjeets:I was facing the exact same error for synthetic fields
15:30:43 <ihrachys> electrocucaracha: but first, model moves, then objects with adoption, in parallel we will look at forbidding contraction
15:31:08 <ihrachys> and supporting folks in evolving db for their respective features
15:31:20 <ihrachys> without the latter, the plan of no contraction will not happen
15:31:46 <electrocucaracha> ihrachys: this is only in the neutron scope right, without covering stadium projects
15:32:01 <ihrachys> no, just neutron repo so far.
15:32:13 <ihrachys> we may look at *aas maybe, but I would suggest we don't for the first phase
15:32:38 <manjeets> ihrachys, to forbid contract is downgrade option would be removed ?
15:32:44 <manjeets> from neutron db-manage
15:32:45 <korzen> ihrachys, it would be nice to have spec for no API downtime by the summit
15:32:50 <ihrachys> manjeets: downgrade was removed like several cycles ago
15:33:16 <ihrachys> korzen: makes sense, let me put that in my high prio list :)
15:33:21 <manjeets> ok so it is already not there what else is needed to forbid downgrade ?
15:33:32 <manjeets> contract I mean
15:33:36 <korzen> ihrachys, if you need any help, let me know
15:34:10 <ihrachys> manjeets: I don't follow, sorry. downgrade is a feature that allows you to go back in time for db schema
15:34:19 <ihrachys> manjeets: it has nothing to do with no-downtime upgrade
15:34:47 <manjeets> ok contract migration is which removing something from schema
15:34:55 <manjeets> i related it with downgrade
15:35:00 <ihrachys> manjeets: as for what's needed, technically nothing, but we need object facades so that people can evolve schema
15:35:01 <manjeets> got it now
15:35:45 <ihrachys> manjeets: so every time people will come up with an idea of db schema change, we need to provide them with tools (facade) and ideas on how to make it the new way
15:36:42 <ihrachys> #topic Open discussion
15:36:50 <ihrachys> any more topics to cover?
15:37:10 <manjeets> ihrachys, i think i rebased your dns objects on top of your patch
15:37:16 <ihrachys> we don't have the summit etherpad started yet. we may need to think in advance if we need community attention to any work we track there.
15:37:37 <manjeets> I guess a unit test in ports patch is messing up
15:37:48 <ihrachys> manjeets: ack. we need to land those two bits (ports and networks) asap, I will talk to armax next time we have a session with him
15:37:56 <korzen> manjeets, which one?
15:38:34 <manjeets> korzen, https://review.openstack.org/#/c/334695/
15:38:45 <manjeets> https://review.openstack.org/#/c/369744/
15:39:20 <manjeets> ihrachys, not related to upgrades but a point would virtual attendance work for design summit this time ?
15:39:26 <korzen> manjeets, you need to rebase to PS30
15:39:32 <korzen> port patch PS30
15:39:44 <ihrachys> manjeets: I don't think so. it never worked.
15:40:01 <ihrachys> manjeets: hell, it doesn't even work if you are in the room but sit far from the front...
15:40:19 <korzen> ihrachys, true
15:40:20 <ihrachys> manjeets: it's usually people shouting 'please use the mic' from the back
15:40:20 <manjeets> i wonder how it works for other projects
15:40:46 <korzen> I know that midcycles for cinder are available online
15:40:52 <manjeets> ironic too
15:41:13 <korzen> but nova, neutron is too much community
15:41:16 <ihrachys> korzen: yeah, midcycles could in theory work because of smaller room and all. but design summits? nope, I don't see it working in any case.
15:42:18 <electrocucaracha> ihrachys: we noticed that IPAvailabilityRange model was removed during newton release, are you aware of others?
15:42:53 <korzen> electrocucaracha, I had even patch with OVO and adoption ready for it :P
15:42:54 <ihrachys> electrocucaracha: oh right, it's not used anymore
15:43:15 <ihrachys> electrocucaracha: the only reason it was there is to detect collisions, and I believe it's now in solved some other way
15:43:42 <korzen> I gues it is done in netaddr lib
15:43:50 <korzen> IPRange or smth
15:44:14 <electrocucaracha> korzen: yes, that's my concern... having that kind of effort ending in abandoned changes
15:44:52 <ihrachys> electrocucaracha: unless you track all efforts in neutron, you can't know about everytihng
15:45:13 <korzen> unless you touch it with a stick, nobody will tell you it is outdated
15:45:35 <korzen> or when you break smth :)
15:46:49 <electrocucaracha> I personally like the biweekly report that korzen was sending
15:47:02 <ihrachys> electrocucaracha: up to prepare it?
15:47:11 <manjeets> electrocucaracha, to mailing list ??
15:47:50 <ihrachys> I think it's just that some people were pulled into 'other stuff' (like releasing newton), so there was no one to prepare it
15:47:51 <electrocucaracha> ihrachys: I can do my best, I was thinking to include some of the changes that we're planning to do
15:48:22 <ihrachys> electrocucaracha: ack, let's do it this way - you will write up something in etherpad, then ask someone to review it, and sen
15:48:24 <ihrachys> *send
15:48:34 <electrocucaracha> +1
15:48:43 <ihrachys> ok I will wait for your ping ;)
15:49:02 <ihrachys> ok, any more topics to cover, or we close the meeting?
15:49:44 <ihrachys> ok thanks everyone for joining
15:49:49 <ihrachys> #endmeeting