15:00:42 <mpeterson> #startmeeting weekly meeting
15:00:42 <odl_meetbot> Meeting started Mon Apr 16 15:00:42 2018 UTC.  The chair is mpeterson. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:00:42 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:42 <odl_meetbot> The meeting name has been set to 'weekly_meeting'
15:00:53 <mpeterson> #topic Agenda
15:00:55 <mpeterson> Any topics to discuss? Topics I have are: action items from last meeting, announcements, patches
15:00:56 <mkolesni> is it possible to move this 1 hour earlier?
15:01:03 <poothia__> #info poothia
15:01:23 <mpeterson> poothia__: there is no need to issue an #info, the meetbot knows yu are here if you talk
15:01:36 <poothia__> ok... :)
15:01:47 <manjeets> mkolesni, I have no issues with moving it an hour early
15:02:03 <mkolesni> yamahata, ?
15:02:12 <mpeterson> poothia__: you too are ok with the meeting moving 1 hour earlier?
15:02:13 <rajivk> mkolesni, may be we can move it by 30 minutes. Is that ok?
15:02:38 <mpeterson> rajivk: it's actually a bit late already here... 1 hour is difficult for you?
15:02:44 <mkolesni> rajivk, 1 hour is better, if we cant then it can stay as is i guess
15:03:16 <rajivk> mkolesni, mpeterson, i might miss sometimes if we make it one hours earlier
15:03:37 <mpeterson> mmm then I think it's better to leave it as is, what do you think mkolesni ?
15:03:55 <mkolesni> ok but i might miss it from time to time
15:04:17 <rajivk> mkolesni, i can give you 15 more minutes.
15:04:24 <mpeterson> oh... then it's a complicated situation
15:04:36 <mkolesni> no lets leave it like this then
15:04:54 <mkolesni> well see how this goes
15:04:58 <mpeterson> okey, any topics other than the ones I said?
15:05:03 <mpeterson> so we can move forward
15:05:25 <manjeets> I guess since mkolesni is present today we can go over bug list later
15:05:37 <mkolesni> ok
15:05:43 <mpeterson> okey, I'll add it and we'll see how the time goes
15:06:41 <mpeterson> #info added topics: v3 driver, bug triage
15:06:48 <mpeterson> ##topic Action items from last meeting
15:06:49 <mpeterson> #topic Action items from last meeting
15:07:06 <mpeterson> okey, so we have some outstanding actions
15:07:20 <mpeterson> #action mkolesni, yamahata, manjeets to review Ml2 for new full sync
15:07:35 <mpeterson> #action manjeets to review https://review.openstack.org/#/c/529537/
15:07:53 <mpeterson> please try to do those for next time, so we can move forward
15:08:06 <mkolesni> this is a short week here btw, only 1 work day left
15:08:20 <mpeterson> mkolesni: true that, perhaps the rest can do more
15:08:32 <manjeets> mpeterson, I'll out of office from tomorrow for a conference, but will try for sure to get those done
15:08:43 <mpeterson> manjeets: thanks
15:08:46 <mpeterson> #topic Announcements
15:09:15 <mpeterson> anyone has an announcement? nothing on my part and the PTL is not here :(
15:10:17 <mpeterson> I'm going to assume that's a no
15:10:17 <manjeets> I may need reviews on l3 flavors driver, but waiting on neutron-lib release to unbreak patch in neutron which is needed for n-odl
15:10:35 <manjeets> but code reviews can still help
15:10:44 <mpeterson> #info no announcements
15:10:53 <mpeterson> #topic Patches
15:11:16 <mpeterson> okey, so what's the review topic/patch that you want us to review?
15:11:22 <mpeterson> manjeets: ^^
15:11:37 <manjeets> https://review.openstack.org/#/c/504182/
15:11:44 <manjeets> https://review.openstack.org/#/c/544116/2
15:11:50 <manjeets> functional tests are also coming
15:12:35 <mpeterson> #action all to review L3 ( https://review.openstack.org/#/c/504182/ and https://review.openstack.org/#/c/544116/2 )
15:12:47 <mpeterson> manjeets: I don't think I'll be able to review it before the next meeting but I'll do my best
15:12:58 <manjeets> mpeterson, np thanks !
15:13:26 <mpeterson> on my part, I'd need people to start reviewing the implementation of the enginefacade in ODL
15:13:48 <mpeterson> #action all to review bp/enginefacade-switch ( https://review.openstack.org/#/q/status:open+project:openstack/networking-odl+branch:master+topic:bp/enginefacade-switch )
15:14:19 <mpeterson> anything else on patches?
15:15:20 <mpeterson> moving to the next topic in 20 seconds
15:15:32 <rajivk> yes
15:15:48 <rajivk> it would be great if your guys could review https://review.openstack.org/#/c/558554/
15:16:11 <rajivk> and of course full sync and recovery one https://review.openstack.org/#/c/527391/
15:16:41 <mpeterson> rajivk: yes, they are in the todo list already, on actions from last meeting
15:17:10 <mpeterson> oh, the first one isn't
15:17:37 <mpeterson> #action all to review the feature negotiation patch https://review.openstack.org/#/c/558554/
15:18:05 <mpeterson> a lot of work to do it seems
15:18:16 <mpeterson> okey, moving on
15:18:18 <mpeterson> #topic v3 driver
15:18:19 <mkolesni> its a good thing :)
15:18:27 <mpeterson> mkolesni: indeed
15:19:07 <manjeets> are you guys coming with new v3 drivers ?
15:19:16 <mpeterson> as it was brought mkolesni during the PTG, networking-ovn has a better solution to what our journal triest ot solve
15:19:16 <manjeets> comin up**
15:19:39 <mpeterson> this solution is based on the revision number that's present in neutron's standard attributes
15:19:42 <mkolesni> manjeets, didnt isaku update about that?
15:19:52 <manjeets> oh yes there's note on etherpad too
15:20:00 <mkolesni> ok
15:20:04 <mpeterson> and it's quite simple and nice
15:20:08 <manjeets> he did update me but it was out of my mind atm
15:20:14 <mkolesni> :)
15:20:29 <manjeets> ok, I actually need to look at how n-ovn does it to get more details
15:20:58 <mpeterson> I'm working on a spec for the integration in neutron
15:21:12 <mpeterson> so several drivers can leverage from one implementation
15:21:12 <mkolesni> mpeterson, can u please post the link to ovn spec?
15:21:23 <mpeterson> but for a rough idea you can read the ovn spec https://github.com/openstack/networking-ovn/blob/master/doc/source/contributor/design/database_consistency.rst
15:21:28 <mkolesni> so that everyone can later read to get the context
15:21:35 <mkolesni> mpeterson, 10x
15:21:56 <mpeterson> #info we are looking to implement OVN's spec in neutron in a more generic way, mpeterson is working on it (ovn implementation: https://github.com/openstack/networking-ovn/blob/master/doc/source/contributor/design/database_consistency.rst )
15:23:29 <mpeterson> by implementing this idea also we get to do full_sync in a much easier way, and also recovery might not be needed at all
15:24:16 <mpeterson> #action all make yourselves familiar with the design and if you have any ideas/questions/contributions, you can contact me so I can included/answer them
15:24:22 <mkolesni> there are many benefits
15:24:35 <mkolesni> do you want me to list the ones i have in mind?
15:24:44 <mpeterson> mkolesni: yes, that would be nice
15:24:51 <mkolesni> ok
15:25:20 <mkolesni> first, obviously, shared code increases maintainability since we'll have more eyes on it to fix any bugs or add new features
15:25:26 <mpeterson> #info mkolesni will list many of the benefits, you can read the irclogs of the meeting to have an idea
15:25:48 <mkolesni> second, the solution is quite nice and elegant so it is much more maintainable by itself
15:26:20 <manjeets> mkolesni, sharing code with networking-ovn right (is neutron-lib gonna be home for all the common code ?)
15:26:23 <mkolesni> also since it is shared and separated from our core driver code, we can focus on the core aspects of integration with odl
15:27:02 <mkolesni> manjeets, yes, also possibly other drivers will join as there has been interest from dragonflow, l2gw and even possibly midonet
15:27:35 <manjeets> neutron-lib is better atleast some of the maintenance will be offloaded from n-odl
15:27:44 <mkolesni> as to the location, the consensus reached with neutron PTL is to place it where is most convenient for us so it could be neutron or neutron-lib
15:28:11 <mkolesni> since theres a db migration involved this probably fits in neutron more
15:28:19 <mkolesni> but it can always move as necessary
15:28:37 <mkolesni> anyway back to the benefits
15:29:02 <manjeets> ok neutron and neutron-lib both have good attention from cores so maintenance will be good unless they spin a new repo for all this sharing stuff
15:29:17 <mkolesni> since the implemntation is simple and will be an infrastructure, our code will be much simpler so easier to maintain and less bug prone
15:29:35 <mkolesni> and also a major aspect i predict a benefit is performance
15:29:42 <mkolesni> here the benefit is twofold
15:30:13 <mkolesni> one is because the scalability of the n-ovn solution is much better since it scales per resource whereas journal scales per operation
15:30:21 <manjeets> mkolesni, how about CI (it will be reliable on outside repo, so can get little tricky sometimes)
15:30:31 <mkolesni> so it puts a very small overhead per resource
15:30:51 <mkolesni> manjeets, lets discuss this in a sec
15:31:10 <mkolesni> also the other benefit is that in the n-odl model the journal is a bottleneck
15:31:28 <mkolesni> so even for normal operation everything must go through the journal queue to get handled
15:32:12 <mkolesni> in the n-ovn solution only the erronous stuff will get handled in a queue, while normal operation will just happen as part of the normal synchronous flow of each operation
15:32:31 <mkolesni> i.e. if i create a port, the postcommit will actually try to sync the port to odl
15:32:43 <mkolesni> if it succeeds, great, were done with that
15:32:58 <mkolesni> and only if it fails will it be picked up later by the maintenance thread
15:33:13 <manjeets> mkolesni, so there will be journaling for failed operations only ?
15:33:16 <mpeterson> an added potential advantage we discussed today is that it might not even need locks :)
15:33:20 <mkolesni> this, i believe, with be more performant under load since you dont have a bottlenect
15:33:39 <mkolesni> mpeterson, indeed
15:34:10 <mkolesni> brb
15:34:44 <rajivk> mkolesni, thanks for listing, but i think, majority of the people don't know the approach. The better idea, will be to hand over these benefit to Peterson, he will compile them in good format and then everyone can relate all these things.
15:35:11 <mpeterson> rajivk: the spec lists the benefits and compares it to our journaling method
15:35:29 <rajivk> mpeterson, that is great.
15:35:36 <mpeterson> rajivk: and the new spec that I'm working on will probably expand on that
15:35:58 <mpeterson> manjeets: yes, failed operations will be defered to be handled by a maintenance task
15:36:08 <rajivk> mpeterson, if you have some data from PoC or networking-ovn data, it will be excellent.
15:36:11 <mkolesni> ok back
15:36:27 <mpeterson> rajivk: what kind of data ?
15:36:27 <mkolesni> im not sure what your concern about ci is, manjeets
15:36:44 <mkolesni> we will still have tests to see that odl is synced on various operations
15:36:45 <rajivk> anything which gives insight about scalability or performance improvement
15:37:23 <mpeterson> rajivk: I'll ask the ovn maintainer if he re ran the scalability/performance tests after implementing this solution
15:37:25 <mkolesni> mpeterson, you can ask lucas for the scale data, i know they did a scale run about a month ago
15:37:54 <mpeterson> #action mpeterson to ask OVN's maintainer for scale data on this solution, so it can be added to the spec
15:37:58 <manjeets> mkolesni, not really concerns, but it may get little hard to get fixes, it ci is broken because of changes in outside repo
15:38:03 <rajivk> mpeterson, this kind of data will make spec more impactfull
15:38:13 <mpeterson> rajivk: indeed
15:38:27 <mpeterson> manjeets: it's like when neutron makes a change, I also don't see the concern :/
15:38:36 <mpeterson> manjeets: or any other dependency for that matter
15:39:13 <manjeets> yes, as I said not really a concern, we would be little more reliant on dependencies
15:39:15 <mkolesni> the ci for odl will remain a part of n-odl
15:39:33 <mpeterson> said that, like I mentioned to you today mkolesni, I think neutron-lib would be better suited as networking-* cores are also cores of neutron-lib
15:39:38 <mkolesni> just the ci for this infra will be there, but i expect it not to change that much anyway
15:39:59 <mkolesni> mpeterson, yes but afaik it doesnt have db migration scripts
15:40:10 <mkolesni> so how would you tackle the need?
15:40:40 <mpeterson> mkolesni: we can talk with the neutron core team and see what they say
15:41:07 <mpeterson> anyways, I do agree with mkolesni that the concerns over the CI shouldn't be too many
15:41:48 <mkolesni> mpeterson, you can write both options in the spec and see the replies
15:41:56 <manjeets> mkolesni, ++
15:42:02 <mpeterson> indeed
15:42:22 <mkolesni> ok so mpeterson i working on the spec and should have a draft ready next week, right?
15:42:30 <mpeterson> mkolesni: correct
15:42:39 <mkolesni> cool
15:42:49 <manjeets> looking forward to review the spec
15:43:18 <mpeterson> oh, and btw, we want to target rocky
15:43:33 <mkolesni> the goal is to have it as poc in rocky
15:43:34 <mpeterson> so this work should be done before July 23rd
15:43:37 <manjeets> that might be tight though
15:43:45 <mkolesni> ans stabilize on stein
15:43:52 <mpeterson> right
15:44:04 <mkolesni> the code is already there but needs to be extracted
15:44:26 <mpeterson> indeed
15:44:28 <mpeterson> and it's quite simple
15:44:30 <mpeterson> let me show you
15:44:47 <mpeterson> https://github.com/openstack/networking-ovn/blob/f3f5257fc465bbf44d589cc16e9ef7781f6b5b1d/networking_ovn/db/revision.py
15:44:58 <mpeterson> 128 lines for the core code
15:45:19 <mpeterson> an extra 62 for the maintenance utilities https://github.com/openstack/networking-ovn/blob/f3f5257fc465bbf44d589cc16e9ef7781f6b5b1d/networking_ovn/db/maintenance.py
15:45:31 <mkolesni> btw on the ptg we had positive response from the neutron ptl and the people there, so its attainable i believe
15:46:03 <manjeets> question does ovn has db migration scripts inside it ?
15:46:11 <manjeets> n-ovn**
15:46:15 <mpeterson> yes, and a strong and well polished spec based on the one from OVN + OVN's success will allow it to move even faster
15:46:23 <mpeterson> manjeets: yes
15:47:16 <mpeterson> manjeets: you can find it in networking-ovn/db/
15:48:11 <mpeterson> I think we won't have time to do the bug triage today
15:48:23 <mpeterson> so, any other questions regarding this?
15:48:28 <mpeterson> or we can adjourn the meeting?
15:48:33 <manjeets> next time then
15:48:54 <manjeets> I guess im good to go, need to read spec before I have questions
15:48:59 <mkolesni> i think everyone can read the n-ovn spec
15:49:11 <mpeterson> manjeets: offtopic, you are in India or USA?
15:49:15 <mkolesni> and then for next week when you have the spec ready we will go over that
15:49:28 <manjeets> manjeets, Oregon,Usa
15:49:31 <mpeterson> mkolesni: sounds good, I'll add it as an action
15:49:32 <manjeets> mpeterson, ^^
15:49:50 <mpeterson> manjeets: nice :)
15:49:50 <mkolesni> oh no manjeets is talking to himself ;)
15:49:58 <mpeterson> hahaha it already started
15:50:13 <manjeets> mkolesni, m and tab magic
15:50:19 <mkolesni> indeed
15:50:24 <mkolesni> so many options :)
15:51:08 <mpeterson> #action all to read the OVN spec to familiarize, will be a topic next week's meeting for more input from everyone
15:51:20 <mpeterson> so, that's it...
15:51:20 <mkolesni> cool
15:51:22 <mpeterson> #topic Bug triage
15:51:29 <mpeterson> #info skipped, lack of time
15:51:39 <mpeterson> that's it
15:51:41 <mpeterson> #endmeeting