16:03:21 <yamahata> #startmeeting neutron_northbound
16:03:21 <odl_meetbot> Meeting started Mon Mar  6 16:03:21 2017 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:03:21 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:21 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
16:03:51 <yamahata> #chair mkolesni vthapar
16:03:51 <odl_meetbot> Current chairs: mkolesni vthapar yamahata
16:03:55 <reedip_1> o/
16:04:01 <yamahata> #topic agenda bashing and roll call
16:04:07 <yamahata> reedip_1: hello
16:04:11 <mkolesni> #info mkolesni
16:04:11 <yamahata> #info yamahata
16:04:16 <vthapar> #info vthapar
16:04:38 <reedip_1> #info reedip
16:04:45 <yamahata> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings meeting agenda
16:04:46 <rajivk_> #info rajivk
16:05:10 <yamahata> any additional topics?
16:05:44 <yamahata> For patches/bugs, we usually have a topic for it.
16:06:49 <yamahata> seems nothing additional.
16:06:51 <yamahata> move on
16:06:52 <yamahata> #topic action items from last meeting
16:07:00 <yamahata> yamahata will communicate with openstack release team.
16:07:12 <yamahata> Not yet. I'll send a mail on it this week.
16:07:44 <yamahata> #action yamahata update agenda page.
16:08:00 <yamahata> It has still old items. needs to be update for Pike.
16:08:21 <yamahata> #topic Ocata postmortem/Pike planning
16:08:44 <yamahata> #link https://blueprints.launchpad.net/networking-odl blueprint for Pike cycle
16:08:48 <mkolesni> we need to do specs again
16:09:03 <yamahata> #link https://bugs.launchpad.net/networking-odl/+bugs?field.tag=rfe rfe bugs
16:09:15 <yamahata> mkolesni: sure.
16:09:40 <yamahata> #link https://etherpad.openstack.org/p/Networking-odl-Pike pike planning ether pad
16:10:02 <mkolesni> personally i want to work on moving dependency checks to journal entry creation phase
16:10:07 <yamahata> Have we filed necessary blueprint/rfe bugs?
16:10:29 <mkolesni> i will file a bp and draft a spec for this
16:10:50 <yamahata> Great.
16:11:03 <yamahata> #action mkolesni file a bp and draft a spec for  journal entry creation phase
16:11:20 <mkolesni> whoever wants to work on something should draft a spec if its a big feature
16:11:33 <mkolesni> if its something small then just rfe should be enough
16:11:36 <yamahata> we can close https://blueprints.launchpad.net/networking-odl/+spec/journal-recovery for ocata?
16:12:27 <mkolesni> yes i believe so ill move it to closed
16:12:49 <yamahata> #action mkolesni  close https://blueprints.launchpad.net/networking-odl/+spec/journal-recovery
16:13:11 <yamahata> I also think we can also close https://blueprints.launchpad.net/networking-odl/+spec/l2gateway-v2-driver
16:13:23 <yamahata> functional test remains. It can be tracked as rfe bug.
16:14:01 <yamahata> #action yamahata close https://blueprints.launchpad.net/networking-odl/+spec/l2gateway-v2-driver  and file rfe bug for functional test for l2gateway
16:14:28 <yamahata> #action yamahata update blueprint for other drivers
16:14:29 <rajivk_> yamahata, sorry to interrupt
16:14:36 <yamahata> rajivk: yes?
16:14:41 <rajivk_> is it necessary to close blueprint after release?
16:15:09 <mkolesni> if it has been implemented
16:15:10 <yamahata> at least we should update them. close or move it to the next cycle etc.
16:15:15 <rajivk_> I mean, we can close once it has actually completed. So that all the data related to a feature can be found at one place.
16:15:35 <manjeets> rajivk, hi
16:15:45 <rajivk_> manjeets, hi
16:16:09 <mkolesni> sounds reasonable
16:16:12 <reedip_1> yamahatha  : hi
16:16:13 <yamahata> rajivk: if it's not completed, are you claiming that we should move it to the next cycle?
16:16:37 <reedip_1> I agree with rajivk , it can be moved to the next cycle. We can track the FT test cases in the BP itself
16:16:38 <rajivk_> yes
16:17:03 <yamahata> okay I'm fine with that. Then let's move l2gateway to pike to track the remaining task.
16:17:12 <manjeets> i was on other neutron meeting
16:17:21 <rajivk_> Actually, it helps new comer they find all the information related to a bug at one place.
16:18:02 <rajivk_> yamahata, if possible, can we do it for all such bps?
16:18:21 <yamahata> rajivk: I'm quite fine with that.
16:18:30 <yamahata> any comments/thoughts?
16:18:43 <mkolesni> +1
16:18:55 <vthapar> +1
16:18:57 <mkolesni> you can comment on bp that impl is in ocata
16:19:13 <rajivk_> yeah that will be great.
16:19:21 <yamahata> So let's do so.
16:20:03 <yamahata> #agreed Unless the all feature is completed, move bp/spec to the next cycle so that  it helps new comer they find all the information related to a bug at one place.
16:20:56 <yamahata> anything on bp/spec?
16:21:13 <reedip_1> do we have  a bp for taas driver?
16:21:40 <reedip_1> tap-as-a-service*
16:21:49 <yamahata> Oh I can't find it. Rui hasn't created it yet.
16:22:04 <rajivk_> reedip, there is a patch https://review.openstack.org/#/c/415334/
16:22:09 <reedip_1> ok, i will create it, if its ok/?
16:22:19 <yamahata> reedip_1: please go ahead
16:22:28 <yamahata> #action reedip_1 create bp for tap-aas
16:22:41 <reedip_1> rajivk_ :i know, m working on it :)
16:22:58 <yamahata> bp for FWaaS is also missing?
16:23:05 <reedip_1> yep
16:23:25 <yamahata> reedip_1: can you please also take care of it?
16:23:30 <reedip_1> yes
16:23:49 <yamahata> #action reedip_1 create bp for FWaaSv2
16:24:31 <yamahata> anything else?
16:24:41 <rajivk_> yes
16:25:02 <rajivk_> As per discussion in PTG, i am working on
16:25:10 <rajivk_> https://blueprints.launchpad.net/networking-odl/+spec/patch-scrub
16:25:33 <yamahata> cool
16:25:34 <rajivk_> Are we going to discuss about it later on or should I discuss now?
16:25:55 <yamahata> Regarding to each patches/bugs, we'll discuss later
16:26:24 <rajivk_> thanks, I would like to discuss about https://blueprints.launchpad.net/networking-odl/+spec/documentation
16:26:47 <yamahata> rajivk: go ahead.
16:26:58 <reedip_1> rajivk_ +1
16:27:13 <rajivk_> This blueprint has many items to cover, can we discuss scope of it?
16:27:26 <rajivk_> or we going to have this discussion latter on?
16:27:27 <yamahata> sure.
16:27:45 <yamahata> Let's discuss on it now.
16:28:09 <rajivk_> ok, I want to work on "first step-by-step guide or tutorial"
16:28:21 <rajivk_> What should be the content of this section?
16:28:26 <yamahata> I suppose we'll have rfe bugs for each documents once we have assignee.
16:28:35 <rajivk_> How much detailed it should be?
16:28:59 <yamahata> I expected that new comer like you can follow it and setup developer environment.
16:29:18 <manjeets> rajivk, were you able to set up dev env ?
16:29:25 <yamahata> because you and other new comer complained the lack of documentation and wanted to know where to start.
16:29:41 <vthapar> yamahata: we're going for devstack based setup for documentation?
16:29:45 <rajivk_> manjeets, thanks a lot for your help.
16:29:49 <mkolesni> maybe also need to doc devstack
16:30:03 <reedip_1> do we have a doc job for networking-odl?
16:30:04 <rajivk_> Yes, devstack documentation is important.
16:30:06 <yamahata> vthapar: that's what I had in mind. devstack + alpha.
16:30:14 <mkolesni> the basic local.conf file and also advanced features
16:30:37 <manjeets> mkolesni, I have basic conf
16:30:44 <vthapar> #link http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/openstack-guide/index.html
16:30:46 <yamahata> example networking-odl/devstack/local.conf.example is somewhat stale.
16:30:48 <manjeets> which worked on rajivk's dev env
16:31:00 <vthapar> take a look at this too, can decide to link to it, or use this as a starting point.
16:31:10 <vthapar> it includes devstack as well as non-devstack guides.
16:31:11 <rajivk_> ok, i Will put my devstack file and other experts can help to improce :)
16:31:25 <mkolesni> ok
16:31:27 <manjeets> https://github.com/manjeetbhatia/useful_files/blob/master/local_odl.conf
16:31:34 <vthapar> rajivk_: I'd recommend reading the ODL+Openstac guide I gave link for.
16:31:46 <manjeets> let me know if this looks good i can spin off a patch to add it to networking-odl
16:31:50 <rajivk_> vthapar, thanks i will read it.
16:31:59 <manjeets> yamahata, mkolesni ^^
16:32:20 <yamahata> vthapar: do you have native one? the link describes how to migrate from the reference env to networking-odl.
16:32:43 <yamahata> manjeet, can you upload a patch to update the example of local.conf?
16:33:05 <manjeets> #action manjeets to upload a patch to add sample conf
16:33:11 <vthapar> yamahata: no, but it does have sections on devstack further down.
16:33:18 <mkolesni> manjeets, thats old should refer to v2 drivers
16:33:23 <yamahata> vthapar: oh, that's right. I missed it.
16:34:09 <mkolesni> basically this needs update https://github.com/openstack/networking-odl/blob/master/devstack/README.rst
16:34:13 <vthapar> yamahata: primary audience for that one is those who already have a working openstack, so doesn't cover ground on how to get openstack up and running. there is enough documentation for that
16:34:51 <vthapar> mkolesni: isn't README.rst more or less updated as and when patches come in? e.g. v2 drivers already covered in it.
16:36:08 <mkolesni> vthapar, seems theres still reference to v1 drivers there, should be v2 by default
16:36:43 <vthapar> mkolesni: aha! yes, need to update those with v2.
16:36:46 <yamahata> mkolesni: can you please take care of updating README.rst?
16:37:05 <yamahata> Probably it can be tracked by https://blueprints.launchpad.net/networking-odl/+spec/documentation
16:37:06 <mkolesni> yamahata, i thought rajivk_ wanted to update it?
16:37:06 <vthapar> local.conf by manjeets is good idea, but would be good to add comments to it explaining key values, kinda like https://docs.openstack.org/kilo/config-reference/content/section_neutron.conf.html
16:37:14 <mkolesni> if not i dont mind doing it
16:37:28 <yamahata> rajivk: do you want to take it? If so, please go ahead.
16:37:30 <rajivk_> mkolesni, i will
16:37:40 <rajivk_> yes, i will.
16:37:40 <mkolesni> ok
16:37:56 <vthapar> rajivk_, manjeets do add me to any n-odl documentation reviews as I'll be doing documentation in ODL for netvirt.
16:38:02 <yamahata> #action rajivk take care of updating README.rst and update https://blueprints.launchpad.net/networking-odl/+spec/documentation
16:38:34 <manjeets> ok sounds good vthapar
16:38:40 <yamahata> rajivk: do you have any other questions on doc?
16:39:03 <rajivk_> so, i have to work on the part
16:39:03 <yamahata> anyway we can discuss on irc in adhoc way if necessary.
16:39:18 <rajivk_> where new comer are able to setup enviornment.
16:39:19 <yamahata> anything else on spec?
16:39:28 <rajivk_> yes, wait.
16:39:31 <vthapar> yamahata: can we add work items from etherpad to documentation BP?
16:39:45 <yamahata> vthapar: yes off course.
16:39:50 <vthapar> bp should be single place to track.
16:40:05 <rajivk_> vthapar, i will add.
16:40:16 <yamahata> etherpad was for working at PTG, blueprint/spec is the place to track.
16:40:26 <vthapar> thanks rajivk_
16:40:31 <rajivk_> For https://blueprints.launchpad.net/networking-odl/+spec/v2driver-activities-in-pike, i need detail information on this.
16:41:16 <rajivk_> So that i can start reading information necessary to work, besides my documentation and patch-scrub work.
16:42:02 <rajivk_> Either someone provide a brief details of this blueprint or provide their valuable time to discuss.
16:42:04 <yamahata> rajivk: which item do you have doubt on?
16:42:27 <rajivk_> there are 4-5 items on etherpad.
16:43:06 <rajivk_> I would like to understand how much has been completed and how much has to be done?
16:44:02 <mkolesni> yamahata, do you think a spec is needed here to detail how these things are going to be done?
16:44:25 <mkolesni> for example im not sure what "maintenance thread: leader election" means
16:44:31 <yamahata> Yes, if what will be done is not clear to others.
16:44:51 <mkolesni> or what "thread management: introduce threadpool for journal sync thread" means
16:45:03 <yamahata> I think monitoring journal db is clear as the first draft patch is there.
16:45:12 <yamahata> other items would need spec.
16:45:16 <mkolesni> since i wasnt at the PTG (and other people werent as well), design discussion is still a good idea
16:45:17 <rajivk_> I will do that spec part
16:45:42 <rajivk_> Just let me know, a brief idea on the blueprint or with some discussion on IRC.
16:45:53 <vthapar> mkolesni: I believe that (design discussion) is where spec comes in :)
16:46:04 <mkolesni> yes thats what i was talking about
16:47:20 <rajivk_> If someone just provide me links or pointers i will digg them.
16:47:38 <rajivk_> And come up with specs and start working on those items.
16:47:57 <yamahata> we have 13min left.
16:48:24 <mkolesni> rajivk_, https://docs.openstack.org/developer/networking-odl/specs/journal-recovery.html for example is a spec
16:48:25 <yamahata> we can continue to discuss on bp/spec management. or discuss on bugs/patches?
16:48:46 <rajivk_> mkolesni, thanks
16:48:59 <mkolesni> its in the docs dir
16:49:30 <rajivk_> I checked it but i have to understand where leader election etc comes into picture.
16:49:32 <rajivk_> :)
16:49:52 <yamahata> It's for hostconfig, port status update.
16:50:00 <yamahata> in the context of neutron ha.
16:50:14 <mkolesni> i think if somethings not clear we can have discussion on the ML
16:50:14 <yamahata> Maybe it's not documented anywhere.
16:50:19 <mkolesni> before the spec
16:50:41 <mkolesni> spec should be a problem description + design proposal how to solve it
16:50:54 <mkolesni> 096622
16:51:14 <reedip_1> mkolensi : is that a password ?? :)
16:51:25 <yamahata> I guess patch number
16:51:31 <mkolesni> yubikey sometimes gets pressed
16:51:36 <mkolesni> :/
16:51:40 <mkolesni> ignore it
16:51:47 <reedip_1> ok
16:51:55 <yamahata> anything else on bp/spec process?
16:52:16 <yamahata> #topic patches/bugs
16:52:33 <yamahata> we have several patches/bugs to discuss, I suppose. Please go ahead.
16:52:50 <rajivk_> #link https://review.openstack.org/#/c/407784/
16:53:09 <rajivk_> Mike :)
16:53:33 <yamahata> mkolesni: you have mike.
16:53:42 <mkolesni> yes as i alrready said i dont think this should be hard wired to journal
16:54:08 <mkolesni> rather i think a CLI tool to analyze logs will be more handy
16:54:11 <yamahata> oops s/mike/mic/
16:54:12 <mkolesni> and non intrusive
16:54:34 <mkolesni> for this we need to add log entry when journal handling finishes
16:54:41 <yamahata> The chnage to networking_odl/journal/journal.py would be split out to another patch.
16:54:49 <mkolesni> then the CLI tool can scan the log and deduce this info
16:55:15 <mkolesni> no need to change networking_odl/journal/journal.py should only be to add log line
16:55:38 <mkolesni> on production systems you dont integrate constant profiling, which is what this change essentially does
16:55:44 <mkolesni> 175171
16:55:50 <mkolesni> ignore this :/
16:56:56 <mkolesni> you dont agree?
16:57:05 <rajivk_> mkoleni, you mean logs should be added after entries are finished.
16:57:10 <mkolesni> this patch is rather intrusive
16:57:27 <yamahata> mkolesni:  which part of the patch do you mean?
16:57:30 <rajivk_> and later CLI tool will analyze logs and provide information on the basis of provided logs.
16:57:31 <mkolesni> i mean the idea is nice but the implementation is not good
16:57:40 <mkolesni> rajivk_, yes exactly
16:57:50 <mkolesni> we already have log when entry starts processing
16:58:11 <mkolesni> also all these logs need to be on DEBUG level as to not spam production system logs
16:58:18 <yamahata> mkolesni: do you mean asscessing db is intrusive?
16:58:36 <mkolesni> i mean doing all this calculation every time is intrusive
16:58:47 <mkolesni> you will calculate all the time even if this data isnt used
16:58:55 <mkolesni> this is not production friendly
16:59:15 <yamahata> I see.
16:59:30 <yamahata> So 	is networking_odl/journal/stats.py okay with you?
17:00:04 <yamahata> It will be run as independent command.
17:00:21 <rajivk_> mkolesni, if logs are put only if entries are finished then CLI tool can only scan already put information. If we have not put enough information how can it deduce detailed information. Sorry, i am misunderstood.
17:00:42 <mkolesni> i dont think youd want this to act on DB
17:00:53 <mkolesni> lets say i have a production env
17:01:06 <mkolesni> i wouldnt want this script accessing the db even for read only
17:01:27 <mkolesni> the script should analyze logs and take info from there which is very easy to do
17:01:37 <yamahata> Yeah, so the admin can choose not to run the command.
17:01:47 <mkolesni> you just look for when entry processing starts and try to find the end log
17:01:59 <mkolesni> if you find. great - calculate the time difference
17:02:10 <mkolesni> if not, you can report as "never finished"
17:02:20 <mkolesni> i dont see why this needs DB access
17:02:37 <rajivk_> mkolesni, i am sorry, do you mean logs in /var/log/*** location?
17:02:58 <mkolesni> besides, a CLI which analyze logs will make it tenfold easier to do this later offline given a log from a customer deployment, for example
17:03:02 <yamahata> We need to know how long the journal backlog is for devel.
17:03:24 <mkolesni> ok then run it after tempest for example
17:03:41 <mkolesni> rajivk_, the neutron log, usually its in /var/log/neutron/server.log
17:03:52 <mkolesni> but it should be just a parameter
17:04:01 <mkolesni> and could default to that location
17:04:37 <rajivk_> seems good, but i am worried sometimes these logs sizes are huge.
17:04:39 <rajivk_> and we should not trust them,
17:04:47 <mkolesni> i think, as a CLI command, this can be much more useful for developers for example debugging real deployment issues
17:05:18 <rajivk_> because we zip them normally in prodcution at the midnight or something around it.
17:05:25 <mkolesni> well, scanning log file with "grep" like functionality usually is pretty fast even if the logs are huge
17:05:31 <yamahata> you want a sort of postmortem analysis tool, not live monitoring tool.
17:05:33 <yamahata> right?
17:05:41 <mkolesni> yes
17:06:19 <mkolesni> basically this approach would be better IMO
17:06:26 <yamahata> I see, I agree that postmortem tool is good. but I don't see the good reason against live monitoring tool.
17:06:33 <yamahata> We can have both.
17:06:42 <mkolesni> than direct access to DB + constant profiling
17:07:02 <mkolesni> i dont see why you need it if you have the postmortem solution which is much less intrusive
17:07:06 <mkolesni> sorry gtg
17:07:13 <mkolesni> we can further discuss this on the email
17:07:18 <yamahata> okay let's continue next week.
17:07:25 <yamahata> #topic open mike
17:07:29 <mkolesni> bye!
17:07:32 <yamahata> anything else urgent?
17:07:45 <vthapar> I kinda agree with mkolesni on this, or we can hold this till we have benhmark perf numbers
17:07:53 <vthapar> yamahata: bugs.
17:08:02 <yamahata> vthapar: which bug?
17:08:06 <vthapar> #link https://review.openstack.org/#/c/439633/
17:08:11 <vthapar> this is patch for that port_id.
17:08:30 <yamahata> Oh yes, I'd like to make it progress.
17:08:34 <vthapar> other is the l2gw v2 driver
17:09:00 <vthapar> so we agree on the main patch, right?
17:09:23 <yamahata> vthapar: do you mean 439633?
17:09:32 <rajivk_> yamahata, if you are busy. I can take it under patch-scrub :).
17:09:42 <vthapar> Tomas seems to be okay with 0-14 and I didn't see PORT_ID being used anywhere else. what else is TODO on this?
17:09:57 <vthapar> yamahata: yes.
17:10:07 <vthapar> I had one more, bug# https://launchpad.net/bugs/1669681
17:10:08 <yamahata> tomas is okay with the fix.
17:10:29 <vthapar> so only UTs pending for 439633? or is it good to go?
17:10:41 <yamahata> Right. UT remains.
17:10:47 <vthapar> ok.
17:10:52 <yamahata> Once UT is okay, we can merge the patch.
17:11:05 <vthapar> okay. anyone working on it?
17:11:15 <rajivk_> UT?
17:11:23 <vthapar> rajivk_: Unit Tests.
17:11:37 <rajivk_> I am willing to learn.
17:11:52 <yamahata> Right now ritu is working on it. But there are several testcases.
17:12:06 <yamahata> And also test coverage is issue.
17:12:17 <yamahata> networking-odl-coverage-ubuntu-xenial
17:12:28 <vthapar> yamahata: okay. yeah, we should've had tests to catch this in existing UTs.
17:12:50 <yamahata> vthapar: RIght. You're reading my mind.
17:13:24 <vthapar> yamahata: should we have a separate RFE/Bug for improving UTs as well as coverage?
17:13:26 <rajivk_> If you need help, help let me know. But you have to provide me guidance.
17:13:40 <yamahata> vthapar: yes.
17:13:53 <vthapar> rajivk_: woul be good to get in touch with Ritu as she's working on it.
17:14:10 <yamahata> Yes ideally. also I'll remind her.
17:14:14 <rajivk_> I don't find people on IRC.
17:14:31 <rajivk_> What is her IRC nickname?
17:14:35 <yamahata> It's up to people and timezone.
17:14:40 <vthapar> rajivk_: depends on timezones
17:15:08 <vthapar> though at least one of Isaku, Mike or me is always on.
17:15:31 <rajivk_> ok, i will take your help for co-ordination.
17:16:07 <vthapar> yamahata: https://launchpad.net/bugs/1669681 we need this in Ocata too. can you set the importance accordingly?
17:16:41 <yamahata> vthapar: done. set it to critical
17:17:16 <vthapar> yamahata: thanks. I'll work with Deepthi to get patch in good shape.
17:17:43 <yamahata> Once the patch is merged to master, anyone can propose backport.
17:18:52 <yamahata> anything else?
17:18:53 <vthapar> cool, will do that.
17:19:13 <yamahata> we're over about 20min
17:19:14 <vthapar> had a few things, nothing major though and need to head off.
17:19:32 <vthapar> done for now.
17:19:50 <yamahata> thanks everyone
17:19:57 <yamahata> #topic cookies
17:20:04 <yamahata> #endmeeting