15:01:42 <yamahata> #startmeeting neutron_northbound
15:01:42 <odl_meetbot> Meeting started Mon Oct 23 15:01:42 2017 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:01:42 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:42 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:01:46 <mkolesni> sounds good
15:01:50 <yamahata> #chair mkolesni rajivk_
15:01:50 <odl_meetbot> Current chairs: mkolesni rajivk_ yamahata
15:01:58 <yamahata> #topic agenda bashing and roll call
15:02:01 <mkolesni> #info mkolesni
15:02:02 <yamahata> #info yamahata
15:02:09 <mpeterson> #info mpeterson
15:02:10 <rajivk_> #info rajivk
15:02:32 <yamahata> any additional topics today?
15:03:10 <yamahata> or just normal bugs/patches discussion?
15:03:28 <mkolesni> zuul v3 progress?
15:03:47 <mpeterson> sure, why not
15:03:56 <mpeterson> #info zuul v3 progress
15:04:29 <yamahata> anything else?
15:04:33 <mpeterson> not me
15:05:22 <yamahata> okay move on.
15:05:38 <yamahata> #topic Announcements
15:05:47 <yamahata> I don't have except openstack summit.
15:06:08 <yamahata> openstack summit sydny will be held on Nov 6-8.
15:06:19 <yamahata> Unfortunately I won't attend, though.
15:06:36 <yamahata> forum for deveoper/operators will be held there.
15:07:09 <mkolesni> i wont be there either
15:07:21 <mpeterson> #info openstack summit sydney will be held on Nov 6-8, which will hold a forum for devs/operators
15:07:42 <yamahata> anything else to announce?
15:08:20 <yamahata> move on
15:08:25 <yamahata> #topic action items from last meeting
15:08:44 <yamahata> except patch review/bug fixes, we don't have any. so we can move on.
15:08:51 <yamahata> #topic Queens/Oxygen planning
15:09:15 <yamahata> What's the situation of zuulv3?
15:09:35 <mpeterson> it works on master
15:09:35 <yamahata> mpeterson: you're on stage.
15:09:45 <mpeterson> a backport exists for stable/pike
15:09:57 <yamahata> cool.
15:10:05 <yamahata> what about other stable branch?
15:10:16 <mpeterson> and I haven't started to migrate to native jobs yet, since I focused on reviews (outgoing and incoming)
15:10:26 <yamahata> I see.
15:10:30 <mpeterson> yamahata: do we need for other stable branches?
15:10:46 <yamahata> at least ocata needs to be maintained.
15:10:48 <mpeterson> yamahata: if yes, tell me which and I can create the cherry picks
15:10:56 <yamahata> I suppose trivial backport would work.
15:11:19 <mkolesni> probably its mostly if not all new files
15:11:24 <mpeterson> #action mpeterson to create a backport of the Zuul jobs in stable/ocata
15:11:35 <mpeterson> indeed
15:11:47 <yamahata> If trivial backport is possible to newton, it would be desirable.
15:11:58 <mkolesni> i think we need to drop newton no?
15:12:26 <mkolesni> isnt it the openstack policy to only support n, n-1 releases?
15:12:34 <yamahata> right, we can drop newton.
15:12:52 <mpeterson> re: grafana, I need to understand how they differentiate between projects, since now we share jobs cross projects. I'll do that and adjust because we need to understand if the non-voting jobs are stable
15:13:24 <mpeterson> #info zuul v3 jobs fixed in master, backports created for stable/{ocata,pike} and grafana needs updating still
15:14:39 <yamahata> grafana is very helpful to know what's going-on.
15:14:52 <yamahata> mpeterson:  any other updates?
15:15:17 <mpeterson> re zuul v3, nothing else
15:15:27 <yamahata> great.
15:15:48 <yamahata> regarding to planning, I'd like to mention that oxygen M1 passed.
15:15:56 <yamahata> the plan can be found at https://wiki.opendaylight.org/view/NeutronNorthbound:Oxygen_Release_Plan
15:16:14 <yamahata> M1 report can be found at https://git.opendaylight.org/gerrit/#/c/64315/
15:16:21 <mpeterson> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Oxygen_Release_Plan Oxygen Release Plan
15:16:34 <mpeterson> #link https://git.opendaylight.org/gerrit/#/c/64315/ Oxygen M1 report
15:16:40 <yamahata> From oxygen, status report will be written in RST format and committed to doc repo.
15:16:57 <yamahata> Okay, now we can discuss patches/bugs
15:16:59 <yamahata> #topic patches/bugs
15:17:02 <yamahata> any patches/bugs
15:17:10 <mkolesni> yes
15:17:13 <yamahata> I know about sfc patches and rajivk_ UT.
15:17:22 <mkolesni> https://review.openstack.org/#/c/504043/ is pendIng review for quite a while
15:17:45 <mkolesni> can we move it along? i want to backport it to pike
15:18:00 <yamahata> let me review it
15:18:08 <yamahata> #action yamahata review https://review.openstack.org/#/c/504043/
15:18:19 <mkolesni> great thanks
15:18:20 <mpeterson> yamahata: I voted 0. It is your decision to make.
15:18:37 <yamahata> mpeterson: thanks.
15:18:38 <mpeterson> IMHO it is in +1 condition
15:19:18 <mkolesni> mpeterson, you mean from your perspective its a theoretical +1?
15:19:49 <mpeterson> mkolesni: correct. I do think be can benefit from the change in discussion, just is not the place to do it.
15:19:58 <mkolesni> anyway ill soon submit a patch to separate the entry creation anyway as part of another fix
15:20:03 <mkolesni> so i can rebase on top
15:20:15 <mkolesni> but anyway yamahata please do review and provide comments if any
15:20:40 <yamahata> will review them.
15:20:44 <mkolesni> thanks
15:21:15 <yamahata> any other patches/bugs?
15:21:18 <mkolesni> please also review https://review.openstack.org/514354
15:21:21 <mkolesni> and https://review.openstack.org/514355
15:21:43 <mkolesni> its fairly simple changes, to gather more info from the logs
15:21:49 <mpeterson> do we have an outstanding bug that needs urgent work or review?
15:22:13 <mpeterson> #action all to review https://review.openstack.org/#/c/514354/ and https://review.openstack.org/514355
15:22:26 <yamahata> did you split out patches into smaller ones?
15:23:40 <yamahata> for a tool to analyze logs.
15:23:52 <yamahata> I mean https://review.openstack.org/#/c/508826/
15:23:53 <mkolesni> https://review.openstack.org/#/c/514354/
15:24:05 <mkolesni> this is precursor for the entry return upon creation
15:24:12 <mkolesni> i will base all other patches on this one
15:24:33 <yamahata> Oh okay. gotcha.
15:25:05 <mkolesni> this should solve any outstanding issues on this point
15:25:14 <mkolesni> since it will now be needed by several places
15:25:23 <mkolesni> i will also simplify tests once i have the time
15:25:32 <yamahata> Great.
15:26:23 <mkolesni> #action mkolesni to simplify tests to use returned entry
15:27:13 <yamahata> any other patches/bugs?
15:27:21 <yamahata> rajivk: rajivk_  , do you have any?
15:27:24 <rajivk_> yes, https://review.openstack.org/#/c/500366/
15:27:32 <rajivk_> and https://review.openstack.org/#/c/504297/
15:28:27 <rajivk_> yamahata, I can see comments regarding naming.
15:29:12 <mpeterson> #action all review https://review.openstack.org/#/c/500366/ and https://review.openstack.org/#/c/504297/
15:29:26 <yamahata> such naming convention wouldn't needed.
15:29:40 <yamahata> because simply bounded method can be registered.
15:29:57 <yamahata> e.g. self._recovery.
15:30:24 <yamahata> Is dynamic method lookup needed?
15:31:19 <rajivk_> I don't see any benefit of registering methods
15:31:41 <mpeterson> me neither, unless I am missing something in your argument
15:32:44 <rajivk_> yamahata, I can change it, if we have good reason for it
15:32:47 <yamahata> I see. then what's the benefit of dynamic method lookup?
15:33:24 <yamahata> or cons of registering bounded method.
15:33:52 <rajivk_> It is just the consistency nothing else
15:33:57 <rajivk_> i could see for now.
15:34:03 <yamahata> with dynamic method lookup, each driver is required to follow specific naming.
15:34:30 <mkolesni> lets go for the simpler solution
15:34:43 <mpeterson> yes, and what's wrong with that? don't we have similar conventions in other things? __init__ __getattr__ __copy__ etc etc
15:34:48 <mkolesni> do you consider registering simpler?
15:36:00 <mpeterson> registering bound methods means we need to add as many parameters as methods as we need
15:36:08 <yamahata> Yes. __init__ etc convention is widely used and well documented.
15:36:28 <yamahata> On the other hand, this case is very special purpose.
15:36:37 <mpeterson> if we were to add more common functionality that could be registered and acted upon, then we would need to add more parameters
15:36:57 <yamahata> Hmm, if we would go with dynamic method lookup, can we have documentation?
15:37:13 <rajivk_> sure, i will add.
15:37:14 <mpeterson> agreed
15:37:31 <mkolesni> anyway you need dev docs no matter the chosen solution i think
15:37:35 <mkolesni> it always helps
15:37:38 <yamahata> without reading the code, it's difficult to understand why _recovery, method is needed.
15:38:07 <mkolesni> mpeterson, can we use magic method naming or something similar?
15:38:15 <mpeterson> yes, in this case just doctext won't be enough, probably a rst on this should be added/modified
15:38:48 <mpeterson> mkolesni: no, as rajivk_ correctly pointed out, there is some documentation in the python docs that asks to leave __xxx__ methods reserved for Python devs
15:39:21 <mpeterson> mkolesni: similarly, the recommended way to "overcome" this is to use _ or __ methods
15:39:28 <mkolesni> mpeterson, ok
15:40:00 <yamahata> how about introduce base mixin class?
15:40:06 <mpeterson> mkolesni: although there are projects that disregard the request of reservign magic methods and they do use it (ie: sqlalchemy with __table__)
15:40:56 <yamahata> then requirement will be explicit.
15:40:58 <rajivk_> yamahata, __XXXX is used in ResourceSyncer class to take benefit of name mangling to make sure they are not modified outside the class.
15:41:02 <mpeterson> yamahata: I did recommend using an ABC for this, I think we can still do it. The only drawback of this is that if you implement an ABC then you'd have to implement both _recovery and _fullsync
15:41:21 <mkolesni> ok well either way this sounds simpler
15:41:31 <mkolesni> ABC is probably overkill for now
15:41:35 <mpeterson> yamahata: with the current solution you can leave either unimplemented and then a default behavior is given
15:41:57 <rajivk_> yeah, now we are avoiding it, otherwise we will have have atleast a placeholder method.
15:42:04 <mpeterson> yup, I think just documenting it should be enough
15:42:11 <mkolesni> it can also just be a "mix in" type class
15:42:26 <mkolesni> then the default has the default behavior
15:42:46 <mkolesni> and you can create different ones with specialized behavior for either or both methods
15:42:55 <rajivk_> You mean, create a mix in class and define default method their and all drivers inherit it?
15:43:10 <mkolesni> just a suggestion
15:43:22 <mkolesni> i know mixins are considered somewhat ugly
15:43:31 <mkolesni> tho they used in openstack a lot :)
15:43:43 <mpeterson> mkolesni: I'm not a big fan of MixIns except from very few exceptions
15:44:11 <mkolesni> but in this case it will both define the api and provide a default implementation
15:44:24 <mpeterson> mkolesni: yeah, they are used a lot because they are trying to implement ideosincracies of other languages in python
15:44:49 <mkolesni> i think in this case it might be the most convenient choice
15:45:02 <mkolesni> but i dont really have strong feelings for or against this
15:45:20 <mkolesni> i just raised it as another valid option
15:45:52 <mkolesni> you guys are grown up and can decide for yourself whats the best one ;)
15:46:24 <yamahata> we have 15mins left.
15:46:38 <yamahata> maybe we can continue discussion on the review.
15:46:47 <rajivk_> sure
15:46:57 <yamahata> What about https://review.openstack.org/#/c/504297/
15:47:09 <yamahata> It looks like making good progress.
15:47:24 <rajivk_> Got comments from yamamoto and incorporated them.
15:47:46 <rajivk_> From my end, whatever seems ok but need more reviews
15:48:15 <rajivk_> as i have not the complete knowledge, it will be good, if some people, who already worked on this patch can be pulled for review.
15:48:16 <yamahata> superficially the direction looks good.
15:48:21 <yamahata> I'll review it.
15:48:31 <yamahata> But I'm wondering why tempest is failing.
15:48:48 <mkolesni> can you please provide a meaningful commit message?
15:48:54 <mpeterson> something I noticed about that patch is that it seems to break the non-voting tests (the same that we want to enable again)
15:49:21 <rajivk_> ok, i will look into each failure, may be i am missing something.
15:49:50 <mkolesni> probably should be linked to https://blueprints.launchpad.net/networking-odl/+spec/neutron-lib-adoption
15:50:44 <rajivk_> During testing i noticed that update of resources failed for one driver
15:51:02 <rajivk_> But i think, this issue might exist for other driver as well.
15:51:02 <mpeterson> #link https://blueprints.launchpad.net/networking-odl/+spec/neutron-lib-adoption neutron lib adoption blueprint (re: https://review.openstack.org/#/c/504297/)
15:52:10 <mkolesni> sorry i got confused from the commit message this is not related to that
15:52:33 <rajivk_> mkolesni, i will update it.
15:53:37 <mpeterson> #info the above link is not related to the patch
15:54:33 <yamahata> we have 6mins left
15:54:39 <mpeterson> nothing on my side
15:54:40 <yamahata> anything urgent?
15:54:44 <mkolesni> i think we can close
15:54:46 <yamahata> or open mike?
15:54:51 <yamahata> #topic open mike
15:55:19 <yamahata> going once
15:55:30 <mpeterson> sold to the guy on the back!
15:55:39 <yamahata> thank you, every one.
15:55:46 <yamahata> #topic cookies
15:55:51 <yamahata> #endmeeting