15:06:00 <yamahata> #startmeeting neutron_northbound
15:06:00 <odl_meetbot> Meeting started Mon Nov  6 15:06:00 2017 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:06:00 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:06:00 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:06:04 <yamahata> #chair rajivk
15:06:04 <odl_meetbot> Current chairs: rajivk yamahata
15:06:12 <yamahata> #topic agenda bashing and roll call
15:06:16 <yamahata> #info yamahata
15:06:25 <rajivk> #info rajivk
15:06:45 <yamahata> any additional topics?
15:06:54 <yamahata> today I'd like to discuss about timeslot.
15:07:31 <yamahata> Officially Monday at 08:00 PST/PDT, but I'm not sure the attendee is aware of PST/PDT.
15:08:01 <yamahata> Maybe given the current attendee, I should raise it on the mailing list, to follow daylight-saving-time change in US.
15:08:08 <yamahata> any other topics?
15:08:14 <rajivk> no
15:08:34 <yamahata> okay.
15:09:03 <yamahata> #action yamahata send a mail to the mailing list regarding to PDT/PST issue or timeslot.
15:09:17 <yamahata> #topic Announcements
15:09:31 <yamahata> This week there is a openstack summit in sydney.
15:10:14 <yamahata> and the next week Nov 14, 2014 is M2 of ODL. it's feature freeze.
15:10:25 <yamahata> any other announcement?
15:10:43 <rajivk> not from my side.
15:11:47 <mpeterson> wow, wasn't this supposed to be in 1h?
15:12:05 <yamahata> mpeterson: are you aware of daylight-saving time?
15:12:23 <mpeterson> right, I thought the clock changed and thus it was going to be in 1h
15:12:37 <yamahata> Last week I forgot to mention it. So I assumed that no one is aware of it.
15:12:54 <mpeterson> yamahata: oh, we were aware :)
15:13:17 <yamahata> Actually all the attendee except Isaku is out of US.
15:13:50 <mpeterson> so? not sure I follow :)
15:14:26 <yamahata> So I assumed that the attendee wasn't aware of daylight-saving-time change.
15:14:39 <mpeterson> oh
15:14:44 <mpeterson> okey...
15:14:55 <mpeterson> I'm not sure mkolesni will connect to the meeting nevertheless
15:15:01 <yamahata> I'm fine with eitherway. to follow daylight-saving-time or not to.
15:15:05 <mpeterson> so we can continue it now if you want
15:15:11 <mpeterson> I prefer this timeslot actually
15:15:22 <mpeterson> not sure mkolesni and jhershbe though
15:15:47 <yamahata> Anyway I'll send a main on it to the mailing list regarding to timeslot.
15:16:14 <yamahata> This week we have mpeterson and rajivk.
15:16:35 <mpeterson> okey
15:17:13 <yamahata> So what should we do this week? do you prefer to continue or start over in 1h?
15:17:41 <mpeterson> We can continue, we already lost 20 minutes though
15:17:52 <mpeterson> I guess we can overflow if we need
15:18:02 <yamahata> rajivk: how about you?
15:18:16 <rajivk> continue
15:18:48 <yamahata> Okay, let's continue.
15:18:57 <yamahata> #topic action items from last meeting
15:19:06 <mpeterson> okey, so I have some updates on this
15:19:17 <mpeterson> let me find the links, just a sec
15:19:55 <yamahata> action items are only patch review and bug/ci fixes.
15:20:03 <mpeterson> #link https://review.openstack.org/517897 This is the patch that fixes Grafana
15:20:51 <mpeterson> #link https://review.openstack.org/517898 This and all patches that preced are the patches that are requirements for the grafana fix
15:21:02 <yamahata> Oh very cool. grafana has been very good source to understand CI stability.
15:21:52 <mpeterson> #link https://review.openstack.org/#/c/517359/ This one is an experiment with Zuul native jobs for fullstack and functional tests
15:22:01 <mpeterson> that seems to be working btw :D
15:22:22 <mpeterson> or at least it was working until I did a small experimental refactor that I'm now fixing
15:22:34 <mpeterson> and I think that covers my pending action items :)
15:22:44 <yamahata> Perfect!
15:22:56 <yamahata> btw grafana issue is common among openstack project, right?
15:23:19 <mpeterson> yamahata: yes, everyone needs to apply the same fixes
15:23:52 <mpeterson> #action mpeterson to update on Zuul v3 migration status
15:24:38 <yamahata> any other update? rajivk ?
15:25:00 <rajivk> yes
15:25:17 <mpeterson> yamahata: basically two changes happened: 1) the job names changed; 2) job names are now shared across projects/branches so you can't only refer through the job name, you need to specify project and branch
15:25:47 <rajivk> i am still waiting for review on recovery https://review.openstack.org/#/c/500366/
15:26:08 <mpeterson> yamahata: of course that means I need you to +2 +W 517897 and the 2 other patches that that one is based on
15:26:56 <yamahata> I'll review them today.
15:27:03 <yamahata> I love grafana and zuulv3.
15:27:23 <mpeterson> haha why? care to expand :)
15:27:59 <mpeterson> IMHO they have been very careless with the zuulv3 implementation
15:28:18 <yamahata> regarding to 500366 recovery patch, we're getting near to merge.
15:28:33 <yamahata> I'll review it today.
15:28:44 <rajivk> and neutron_lib patch seems to be failing on grenade jobs, manjeets is right. i need to find out.
15:29:02 <yamahata> grafana is very good source to monitor CI stability.
15:29:15 <yamahata> zuulv3 gives us our control on CI.
15:29:46 <yamahata> Especially grafana gives us confidence with actual data.
15:31:37 <yamahata> #topic patches/bugs
15:31:48 <mpeterson> gotcha
15:32:53 <yamahata> rajivk: any other patches to discuss? I suppose recovery patch would be first priority.
15:33:29 <rajivk> yeah, you already told, that you will review it today.
15:33:45 <rajivk> and neutron-lib, i will fix for grenade jobs
15:33:56 <rajivk> however i would like to discus one thing
15:34:13 <yamahata> rajivk: please go ahead.
15:34:29 <rajivk> We have periodic task for sync entries to odl, can not we move into maintenance task
15:34:40 <rajivk> like we have full sync and recovery?
15:35:15 <rajivk> this way, it will save us some from some complexity like, we don't have to run timer to wake thread for processing
15:35:30 <mpeterson> mmmm but maintenance runs sporadically
15:35:43 <mpeterson> whereas sync entries happens more regularly
15:36:19 <rajivk> so may be we can trigger sync as we are doing for driver operations
15:36:33 <rajivk> and the task that we create for maintenance, it will have interval set to low value
15:36:46 <rajivk> like we have now, for timer so similarly we set it low
15:37:29 <rajivk> it will save us from complexity and make code easier
15:37:45 <rajivk> Am i missing something?
15:37:54 <mpeterson> but they cover two different use case
15:38:34 <mpeterson> the driver operations trigger the processing for that operation in particular while the timer makes sure that things that weren't able to process at that time will get processed later
15:39:06 <rajivk> so i am talking about second use case.
15:39:20 <rajivk> i want to keep intact first one and move second one to maintenance
15:40:15 <rajivk> and they will go through same locking mechanism like they are going now, so synchronization problem is still handled the same way
15:40:29 <yamahata> rajivk: The goal is to refactor/simplify the code. you're not seeing issue with it, right?
15:40:53 <rajivk> yes, so i initiated discussion to get your inputs
15:41:00 <mpeterson> rajivk: currently maintenance is set to a 5 minutes interval (default value), you don't want to wait 5 minutes to process something that wasn't able to process in the first use case
15:41:15 <mpeterson> rajivk: example of something that would fall in the second use case
15:41:32 <mpeterson> rajivk: create_network; create_port
15:41:46 <mpeterson> rajivk: create_network won't be able to process until create_port is processed
15:41:54 <rajivk> wait, i mis communicated. but we are going to put it into separate task not in the existing task.
15:42:13 <mpeterson> rajivk: therefore it needs to happen async of the driver op
15:42:20 <mpeterson> okey, I listen :)
15:42:25 <rajivk> i mean, like we have maintenance and pseudo-agent task
15:42:37 <rajivk> we create one more periodic task
15:42:57 <rajivk> and we set low value for that periodic task, we don't use the default value of maintenace
15:43:02 <rajivk> because the task is different
15:43:34 <yamahata> rajivk: do you mean neutron worker?
15:43:36 <rajivk> currently, if we have periodic task framework already
15:44:27 <rajivk> yeah, mpeterson is working on it
15:44:28 <rajivk> https://github.com/openstack/networking-odl/blob/master/networking_odl/journal/periodic_task.py#L29
15:45:37 <yamahata> gotcha
15:45:46 <rajivk> so, we create one more task and while creating worker https://review.openstack.org/#/c/492605/13/networking_odl/journal/worker.py
15:45:51 <rajivk> see in this patch
15:46:17 <rajivk> mpeterson, do you see, we have an option to specify interval here, so it defers from maintenance interval.
15:46:42 <rajivk> if we see logically then we are mixing journal processing and periodic task in current implementation
15:46:58 <mpeterson> now you really got me confused :)
15:47:32 <mpeterson> rajivk: what do you want to do? :/
15:48:05 <rajivk> mpeterson, we actually periodically calls journal sync, right?
15:48:27 <mpeterson> rajivk: on a timer, yes
15:48:33 <mpeterson> rajivk: not as a PeriodicTask
15:48:42 <rajivk> but we are doing it through timer and set(), wait()
15:48:58 <rajivk> mpeterson, i want to make it periodic task that's it.
15:49:48 <mpeterson> rajivk: what advantage would that give?
15:50:17 <rajivk> it makes code simple, we give responsibilities to classes, what they do the best.
15:50:26 <mpeterson> rajivk: it's overkill to use PeriodicTask for it. That class adds a whole different level of complexity to be able to manage more complex scenarios.
15:50:39 <rajivk> periodic task does periodic work, and journal one syncs on demand on operation
15:51:40 <rajivk> mpeterson, that's why i started this discussion
15:51:49 <rajivk> to get your opinions
15:51:59 <rajivk> how does it make complex?
15:52:18 <mpeterson> rajivk: right, right, sorry if I reacted like that :)
15:53:07 <rajivk> :) i just wanted the discussion to start and get your opinion,
15:53:29 <rajivk> it's ok the idea is bad, but i could see it, making things simple.
15:53:32 <mpeterson> rajivk: PeriodicTask is meant to run several operations that you can register and it adds a lot of constraints to the execution (ie: lock, back-to-back) and adds logging as well
15:53:38 <rajivk> yamahata, any comments?
15:54:09 <mpeterson> rajivk: and this is done against the DB, so that means that we would be impacting the DB as well
15:54:19 <yamahata> JournalPeriodicProcessor is already neutron worker. May be we can drop _timer.
15:54:39 <yamahata> But I don't see benefit to use db for global locking.
15:55:19 <yamahata> journal periodic syncer is for HA and for rescuing entries dropped on the follow for some reasons.
15:56:04 <yamahata> If you're seeing actual issue, the story would be different.
15:56:37 <mpeterson> yamahata: you mean running without a timer and executing on a loop?
15:56:59 <rajivk> yamahata, i am not seeing issue, just wanted to make code more simple.
15:57:11 <yamahata> yamahata: RIght, maybe. I'm not sure  if it's worthwhile or not.
15:58:31 <rajivk> yamahata, but keeping in loop, at the same time we might have thread triggerred due to neutron operation
15:58:58 <rajivk> currently, it is handled. I am talking, if we keep in loop.
15:59:33 <yamahata> anyway just an idea. I don't see much gain with it.
16:00:25 <yamahata> it's 1 hour.
16:00:36 <yamahata> we can continue disucssion next week.
16:00:42 <yamahata> any other patches to discuss?
16:00:50 <yamahata> patches or bugs/issues.
16:00:59 <rajivk> not from my side
16:01:17 <yamahata> I see a patch on test_odl_l3 from rajivk
16:01:32 <rajivk> yeah, actually that patch is revert in neutron
16:01:34 <yamahata> the patch on neutron was reverted, so it makes sense to make it run.
16:01:50 <rajivk> so, i thought, we can revert our skip as well.
16:02:04 <yamahata> and I can revise a patch to run the tests with both v1 and v2.
16:02:33 <yamahata> okay.
16:02:38 <yamahata> anything else?
16:03:05 <yamahata> It looks like mkolesni and josh won't joint.
16:03:13 <yamahata> #topic open mike
16:03:41 <mpeterson> nothing else
16:03:47 <yamahata> okay, just final caution. next week timeslot may or may not change depending on the discussion.
16:04:00 <yamahata> today I'll send a mail on timeslot
16:04:08 <yamahata> So please be aware of it.
16:04:15 <yamahata> Thank you every one.
16:04:23 <yamahata> #topic cookies
16:04:29 <yamahata> #endmeeting