15:02:56 <yamahata> #startmeeting neutron_northbound
15:02:56 <odl_meetbot> Meeting started Mon Oct 30 15:02:56 2017 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:02:56 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:56 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:03:06 <yamahata> #chair mkolesni rajivk_
15:03:06 <odl_meetbot> Current chairs: mkolesni rajivk_ yamahata
15:03:14 <yamahata> #topic agenda bashing and roll call
15:03:19 <mkolesni> #info mkolesni
15:03:20 <yamahata> #info yamahata
15:03:27 <rajivk_> #info rajivk
15:03:28 <yamahata> any additional topics today?
15:03:56 <mkolesni> nothing from me
15:04:19 <rajivk_> nothing from me as well
15:04:34 <mpeterson> #info mpeterson
15:04:34 <yamahata> cool. today meeting would be short.
15:04:36 <yamahata> #topic Announcements
15:04:50 <yamahata> there will be openstack summit next week.
15:05:08 <yamahata> Oct 20, we passed Queens-1.
15:05:27 <yamahata> the repo is also updated.
15:05:44 <yamahata> The queens-2 milestone is the week of Dec04-08
15:05:56 <yamahata> which is membership freeze
15:06:17 <yamahata> ODL M2 is Nov 14 which is feature freeze.
15:06:26 <yamahata> anything else to announce?
15:06:29 <mpeterson> #info Openstack summit next week
15:06:38 <mpeterson> #Oct 20 we passed Queens-1
15:06:44 <mpeterson> oops
15:06:44 <yamahata> #chair mpeterson
15:06:44 <odl_meetbot> Current chairs: mkolesni mpeterson rajivk_ yamahata
15:06:54 <mpeterson> #info Oct 20 we passed Queens-1
15:07:02 <mpeterson> #info The queens-2 milestone is the week of Dec04-08
15:07:11 <mpeterson> #info  ODL M2 is Nov 14 which is feature freeze.
15:08:18 <yamahata> #topic action items from last meeting
15:08:33 <yamahata> There are only patch reviews and bug fixing.
15:08:46 <yamahata> As of today, master seems healthy and pike branch is passing.
15:08:49 <mpeterson> yes, and I've had not be able to progress my pendings
15:08:58 <mpeterson> re: zuulv3 and grafana
15:09:00 <yamahata> Not sure about ocata.
15:09:06 <mpeterson> due to the CI being broken again
15:09:20 <mpeterson> and I expect it to break yet again even
15:09:34 <mkolesni> mpeterson, u mean the zuul3?
15:09:44 <mpeterson> mkolesni: yes and ergo the CI
15:10:11 <mkolesni> we need to make tempest jobs voting again
15:10:13 <yamahata> #topic patches/bugs
15:10:28 <mkolesni> i also wanted to ask, as part of deprecating v1 drivers do we want to disable/remove the v1 tests?
15:10:49 <mkolesni> though i guess this will lower coverage.. so not sure
15:10:55 <mpeterson> IMHO only after we actually remove the v1 drivers
15:11:12 <rajivk_> +1 mpeterson
15:11:24 <yamahata> +1 removing at the same time to remove driver
15:11:41 <mkolesni> how about skipping them?
15:11:59 <yamahata> Looking at test_odl_l3, it seems like some test cases aren't run with v2 driver.
15:12:03 <rajivk_> mkolesni, is there something wrong in keeping them?
15:12:08 <mpeterson> why would you remove/skip them as long as you still support and have not deprecated the driver?
15:12:25 <mkolesni> we dont support the v1 driver for quite a while
15:12:52 <mkolesni> the benefit would be less noise in test runs
15:12:57 <mkolesni> quicker test runs
15:12:59 <mkolesni> for devs also
15:13:08 <mkolesni> just asking for opinions here
15:13:11 <mpeterson> the driver is still in the repo and the deprecation warning is only for next version
15:13:26 <mpeterson> so IMHO the tests needs to be there until we remove the code
15:14:04 <mpeterson> mkolesni: what we could do, if everyone agrees though, is to create another environment where all v1 goes into
15:14:09 <mpeterson> *tox environment
15:14:38 <mpeterson> that way we can put all the v1 stuff in those environments and only run whenever v1 stuff is modified
15:14:43 <mkolesni> and will it be run on CI?
15:15:17 <mpeterson> the CI can be configured to only run on specific rules
15:15:31 <mpeterson> ie: docs tests only run if you modify .rst files
15:16:03 <mkolesni> ok that sounds like a good compromise, mpeterson do you want to tackle this?
15:16:41 <mpeterson> mkolesni: sure, with your assistance if I needed it
15:16:45 <mkolesni> btw a real use case was last week when a neutron change broke the l3 v1 test
15:17:00 <mkolesni> so i skipped the entire test to unbreak the gate
15:17:04 <mpeterson> mkolesni: well, actually that contradicts your argument :)
15:17:22 <mpeterson> because we need to identify when external changes break our code
15:17:29 <mkolesni> now to fix it is kind of useless since we dont support v1 anyway and its basically in "code freeze" for a while now
15:17:39 <mkolesni> it broke the test code
15:17:42 <mkolesni> not the driver
15:17:45 <yamahata> Actually Testodll3 is not specific to l3 plugin, but it should also run with l3_v2 plugin.
15:18:00 <rajivk_> and if again something similar happens and we don't modify v1 driver, we don't come to know until we next modify v1 driver
15:18:05 <mpeterson> at least we identify it, and I think yamahata now made the required changes to re-enable them
15:18:12 <mkolesni> well then someone with the knowledge should fix it
15:18:13 <yamahata> When removin testcases for v1, we should asses testcases.
15:18:23 <mkolesni> ok
15:19:39 <yamahata> okay, next patches/bugs to discuss?
15:20:53 <yamahata> nothing else to discuss?
15:20:58 <mkolesni> https://review.openstack.org/#/q/status:open+project:openstack/networking-odl+branch:stable/pike
15:21:12 <mkolesni> theres a few backports to pike, can you please review?
15:21:28 <yamahata> Sure. will do
15:21:33 <mpeterson> yamahata: also the forced full sync
15:21:59 <yamahata> Finally I had look at fullsync.
15:22:12 <yamahata> I have several questions. Esepcially forced sync.
15:22:25 <mpeterson> #action to fix l3 tests and remove the skip
15:22:39 <mpeterson> #action to review backports
15:22:53 <mpeterson> yamahata: sure, this is the forum for all to discuss it :)
15:22:59 <yamahata> I suspect the reason for forced sync is that maintenance periodic thread isn't torn down gracefully, right?
15:23:21 <mkolesni> no its going to be used  in upgrade scenario
15:23:33 <mkolesni> im not sure if this is documented or not
15:24:02 <mpeterson> well, the commit messages at least mention this use case
15:24:04 <yamahata> can't we just wait for running maintenance periodic task?
15:24:18 <mpeterson> that can be up to 10 minutes
15:24:19 <yamahata> I'll check new patches.
15:24:34 <mkolesni> mpeterson, it can be more since its configurable
15:24:44 <mpeterson> mkolesni: right
15:25:04 <mpeterson> yamahata: there are use cases where you want to actually force a full sync
15:25:35 <mpeterson> there has been some discussion about the need for it in several forums
15:25:41 <yamahata> I'm talking about force parameter to execute_ops.
15:26:07 <mpeterson> the parameter is to overcome the back-to-back limitation
15:26:08 <yamahata> https://review.openstack.org/#/c/492606/
15:26:30 <mkolesni> yamahata, its an optimization rajivk_ introduced
15:26:47 <mkolesni> but if you want to trigger full sync this optimization needs to be avoided
15:27:07 <mpeterson> yamahata: if you ask me, I would actually be more keen to remove the back-to-back limitation. At least right now, and without having touched that code for a while, I don't see the reasoning of that... as it is running on a periodic task ...
15:27:25 <mkolesni> mpeterson, the reasoning is for ha environment
15:27:33 <mpeterson> oh
15:27:38 <mpeterson> gotcha
15:27:45 <mkolesni> so that if you have N neutron servers the jobs dont get run N times each interval
15:27:52 <mkolesni> fun :)
15:28:10 <rajivk_> mkolesni, i did not look at code for force full sync
15:28:16 <rajivk_> can we do it on restart?
15:28:20 <yamahata> at worse the logic can run at the same time by multiple neutron servers.
15:28:21 <rajivk_> I mean, full sync
15:28:35 <yamahata> without exclusion.
15:28:35 <mpeterson> rajivk_: it has two ways currently (1) restart; (2) signaling through SIGHUP
15:28:35 <mkolesni> yes i think we agreed on ptg restart would be the most simple to force it
15:29:21 <rajivk_> The code is for SIGHUP for restart?
15:29:39 <mpeterson> rajivk_: currently there are patches to do both
15:29:41 <mkolesni> mpeterson, maybe the sighup is overkill right now, we can check with janki/tim
15:29:58 <mkolesni> but for sure there needs to be a way to trigger it
15:30:10 <mpeterson> mkolesni: IMHO it's not bad to leave it there, it's expected for apps to have that behavior
15:30:13 <yamahata> Hmm, there seems miscommunication.
15:30:20 <rajivk_> Can not we bypass back to back logic?
15:30:27 <yamahata> I'm not talking about forcinbly calling the code.
15:30:44 <yamahata> But the parameter, forced=false which is added to execute_ops
15:30:49 <mkolesni> well, expected is a bit broad interpretation :)
15:31:01 <yamahata> by the patch https://review.openstack.org/#/c/492606/
15:31:03 <mkolesni> yamahata, whats the problem with the parameter?
15:31:09 <mpeterson> yamahata: yes, I understood you. Like I said, forced=True just bypasses the back-to-back logic
15:31:35 <mpeterson> rajivk_: that should answer your Q as well
15:32:01 <yamahata> Hmm Probably I understand the issue. I can comment on the patch.
15:32:10 <yamahata> task_already_executed_recently needs to be twisted.
15:32:25 <yamahata> For now I'm fine to continue the discussion on gerrit.
15:33:17 <mpeterson> as you guys want, I think that sometimes IRC is a better tool to avoid too many backs and forths
15:33:55 <yamahata> with forced=True, we should check if other neutron server is running the maintenance task.
15:34:12 <mpeterson> yamahata: that's what the lock is for
15:34:20 <mkolesni> yamahata, i believe that check is still there
15:34:35 <yamahata> Oh, gotcha.
15:34:37 <yamahata> You're right.
15:34:41 <mpeterson> yamahata: there are two mechanisms: 1) back-to-back and 2) lock
15:34:52 <yamahata> I misunderstood it.
15:34:55 <mpeterson> :)
15:34:57 <mpeterson> cool
15:35:26 <yamahata> I thought force means forcinbly run task irreleavant of recent run or lock.
15:35:42 <mpeterson> no problem
15:36:11 <mpeterson> okey, so we can again move those patches forward
15:36:17 <rajivk_> I want recovery patch one to get merged. It is too big, it makes difficult to review and coding, if some changes are needed and can be done in other patch, will be happy to do it in separate patch.
15:36:46 <mpeterson> rajivk_: I think it's very close to being merged
15:37:00 <mpeterson> rajivk_: there aren't too many more comments on it
15:37:22 <mpeterson> rajivk_: obviously mkolesni and yamahata need to do another round of review
15:37:27 <yamahata> agree that it's close for merge
15:37:38 <mpeterson> but it's progressing very well
15:37:40 <mkolesni> i need to review
15:38:03 <rajivk_> yeah, and let me know, when you guys are ok and ready to merge
15:38:15 <rajivk_> i will do some small round of testing.
15:38:17 <mpeterson> #action mkolesni to review recovery patch
15:38:22 <rajivk_> Then we can merge it.
15:38:23 <mpeterson> #action yamahata to review recovery patch
15:38:55 <yamahata> any other patches/bugs to discuss?
15:39:08 <mpeterson> yes
15:39:08 <rajivk_> status update on neutron/lib
15:39:18 <mpeterson> okey, you go first rajivk_
15:39:31 <rajivk_> i did not get much time, but tempest jobs are failing because port is not being binded
15:39:48 <rajivk_> it seems like, hostconfig is not updated.
15:40:13 <rajivk_> that's all on neutron/lib
15:40:15 <rajivk_> mpeterson, you are up
15:40:25 <mpeterson> okey
15:40:37 <mpeterson> it's a thing I've seen several times come up in reviews
15:40:54 <mpeterson> yamahata: you seem to prefer set_override() instead of conf()
15:41:04 <mpeterson> *config
15:41:20 <yamahata> yes, that's the practice of neutron for testcases.
15:41:24 <mpeterson> and the code is getting mixed with one and the other
15:41:29 <mpeterson> yamahata: actually, if you look at https://github.com/openstack/oslo.config/blob/master/oslo_config/fixture.py#L56
15:41:31 <yamahata> Oh, that's bad.
15:41:39 <yamahata> I prefer for consistency.
15:41:52 <mpeterson> yamahata: you'll see that config is a wrapper on set_override and preferred according to that module's doc
15:42:08 <yamahata> Oh I see.
15:43:15 <mpeterson> can we agree on config() instead of set_override() going forward?
15:43:26 <yamahata> I'm fine with that.
15:43:37 <mpeterson> #agree we are going to use config() isntead of set_override() going forward
15:43:46 <mkolesni> mpeterson, can you send a patch to update usages?
15:43:58 <mpeterson> #action search&replace set_override() to config()
15:44:04 <mpeterson> that's what I was writing ;)
15:44:40 <rajivk_> i was thinking, can not we write these kind of jobs to verify, our own guidelines specific to networking-odl :)
15:44:52 <mpeterson> 62 occurences of set_override, lovely...
15:45:16 <mkolesni> sed...?
15:45:25 <mpeterson> rajivk_: we could add linter rules
15:45:48 <mpeterson> mkolesni: of course, I'll do some command line magic
15:46:01 <mpeterson> rajivk_: but is it really worth it?
15:46:26 <rajivk_> atleat it will force new programmer :)
15:46:31 <rajivk_> to be consistent
15:46:41 <mkolesni> maybe if its simple enough
15:46:41 <mpeterson> rajivk_: I mean it's not hard to write linter rules, but it's overkill for a project this size IMHO
15:46:55 <mpeterson> and before you ask, no, I'll not write linter rules :)
15:47:10 <mkolesni> cant we write some hacking rule for this? theres already a few custom ones
15:47:26 <rajivk_> may be line grep and there should be count 1
15:47:31 <rajivk_> something similar
15:47:59 <mpeterson> mkolesni: I think linter is easier, we can leverage on pylint that's already in place or some of the other tools
15:48:15 <mpeterson> rajivk_: that's hacky
15:48:33 <rajivk_> I would like to learn new thing, if it is needed :)
15:48:35 <mkolesni> https://docs.openstack.org/hacking/latest/
15:48:58 <rajivk_> If you guys think, it is over kill we can leave it. But if you think, it is worth doing.
15:49:04 <rajivk_> I am ready for this task.
15:49:29 <mpeterson> I'm good either way.
15:49:36 <mkolesni> if you want check how to add it as hacking rule
15:49:46 <mkolesni> i think is the standard way to do this in openstaclk
15:49:46 <yamahata> either way is okay.
15:50:12 <mpeterson> mkolesni: right, is plugging in on the linter
15:50:17 <mkolesni> The focus of new or changed rules should be to do one of the following
15:50:18 <mkolesni> Substantially increase the reviewability of the code (eg: H301, H303) as they make it easy to understand where symbols come from)
15:50:18 <mkolesni> Catch a common programming error that may arise in the future (H201)
15:50:18 <mkolesni> Prevent a situation that would 100% of the time be -1ed by developers (H903)
15:50:20 <rajivk_> sure, i will have a look at it. And work on it in free time.
15:50:29 <mkolesni> #link https://docs.openstack.org/hacking/latest/user/usage.html#adding-additional-checks
15:50:57 <mkolesni> also good chance it already exists
15:51:10 <rajivk_> I will take it on low priority.
15:51:16 <mkolesni> i dont think were the only openstack project that would want to enforce such a thing
15:51:22 <mkolesni> ok
15:52:08 <yamahata> we have 8mins left
15:52:19 <yamahata> anything else urgent?
15:52:25 <mpeterson> #agree if anyone wants to take on adding hacking rules to check for conventions, feel free to do it
15:53:13 <mpeterson> yamahata: just we need to make sure actively that CI for pike and ocata are fixed, the fixes haven't been merged yet
15:53:24 <yamahata> mpeterson: agreed.
15:53:45 <yamahata> #topic open mike
15:53:50 <yamahata> anything else?
15:53:51 <mpeterson> I mean it has to be a group effort, not only me :)
15:54:03 <mpeterson> I submitted the patches, but we all need to make sure they are approved
15:54:15 <mkolesni> we need to bug stable team
15:54:15 <mpeterson> nothing further
15:54:41 <yamahata> anything else?
15:54:53 <yamahata> or 6mins will be back to you.
15:55:17 <yamahata> thank you every one.
15:55:22 <mpeterson> cheers
15:55:24 <yamahata> #topic cookies
15:55:30 <rajivk_> thank you everyone
15:55:30 <yamahata> #endmeeting