15:00:48 <yamahata> #startmeeting neutron_northbound
15:00:48 <odl_meetbot> Meeting started Mon Jun  5 15:00:48 2017 UTC.  The chair is yamahata. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:00:48 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:48 <odl_meetbot> The meeting name has been set to 'neutron_northbound'
15:01:05 <yamahata> #topic agenda bashing and roll call
15:01:09 <yamahata> #info yamahata
15:01:19 <yamahata> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings
15:01:50 <yamahata> In addition to usual topics, I'd like to share the outcome of opendaylight developer design forum.
15:02:07 <yamahata> any other additional topics?
15:02:27 <rajivk_> no
15:03:12 <yamahata> okay, let's move on.
15:03:19 <yamahata> #topic Announcements
15:03:29 <yamahata> Last week there was opendaylight developer design forum.
15:03:49 <yamahata> #link http://events.linuxfoundation.org/events/opendaylight-developer-design-forum
15:04:23 <yamahata> The release plan was discussed and the nitrogen cycle is short one. planned for september
15:04:33 <yamahata> #link https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan
15:04:48 <yamahata> The planned formal release is Sep 7, 2017.
15:05:35 <yamahata> The project wide theme is karaf4 and all the project will be kicked out, let project in by checking its status.
15:05:55 <yamahata> another big topic is to migrate to JIRA instead of bugzilla.
15:06:07 <yamahata> The more details will come.
15:06:59 <yamahata> Regarding to openstack integration, there were several topics.
15:07:20 <yamahata> openstack rpc from odl, status update
15:07:42 <yamahata> Ericsson people agreed that there are other use cases for openstack rpc from odl.
15:07:56 <yamahata> So it's worthwhile to pursue openstack-rpc theme.
15:08:18 <yamahata> At the same time, they want to pursue dhcp-port-creation as short-middle term solution.
15:08:37 <yamahata> regarding to status-update, fixing websocket is log hanging fruit
15:09:05 <yamahata> so we'll fix it, use it and get benchmark result in nitrogen cycle.
15:09:35 <yamahata> The link to bugzilla is
15:10:08 <yamahata> #link https://bugs.opendaylight.org/show_bug.cgi?id=7845 Websocket implementation doesn't support unsubscribe for notifications
15:10:31 <yamahata> I discussed with Robert vorga on it. According to him, xpath issue that doesn't allow wild card match is bug.
15:10:43 <yamahata> wildcard match should be allowed.
15:10:47 <yamahata> We'll report it.
15:11:09 <yamahata> those are major topics related to openstack integration.
15:11:25 <yamahata> There were several sessions on netvirt, genius etc.
15:11:45 <rajivk_> Do we have a separate online docs for openstack ODL integration?
15:12:13 <rajivk_> like we had etherpad in PTG
15:12:26 <yamahata> #link https://docs.google.com/presentation/d/1SuSIb6kBTxCNm3cAI5O208-tUzfJfKEdu3kKIf8SGTI/edit?usp=sharing
15:12:44 <yamahata> I used that slide.
15:12:52 <yamahata> and also the one by jhershbe
15:13:11 <yamahata> #link https://docs.google.com/a/redhat.com/presentation/d/1gJmpsZsCxwzUMyDS3RUYIu-nIHP_kcYAX2CsS0-IsfQ/edit?usp=sharing
15:13:31 <yamahata> I'm not sure the slide by jhershbe is viewable by anyone.
15:14:00 <rajivk_> yeah they are Redhat internal.
15:14:14 <yamahata> Regarding to other sessions, I suppose the links to slide are posted to ODL mailing list.
15:14:16 <jhershbe> sorry about that all, it's the permissions red hat has for us.  I can grant permissions to any individual but not to everyone. Anyone interested, please send me a gmail address
15:14:51 <yamahata> #link https://wiki.opendaylight.org/view/Events:Nitrogen_Dev_Forum
15:16:16 <yamahata> any questions/comments on ODL DDF?
15:16:25 <jhershbe> yamahata, my battery is dying. I will ping you from home in 45 minutes
15:16:38 <yamahata> jhershbe: okay.
15:17:22 <mbuil> yamahata: the slides say: V2driver: hardening: unstable than v1driver for now. Does that mean we should still use v1 for Carbon?
15:17:23 <yamahata> I also talked with netvirt folks to help fixing tempest issue.
15:17:42 <yamahata> mbuil: Even now v2driver is default.
15:18:06 <yamahata> The reason that v1driver is kept is the failure rate with v2driver is still higher  thank v1driver
15:18:29 <yamahata> #link http://grafana.openstack.org/dashboard/db/networking-odl-failure-rate
15:18:33 <mbuil> yamahata: ok, thanks In OPNFV we are using v2 driver but after reading the slides I was in doubt
15:18:37 <yamahata> It's only for comparition.
15:19:01 <yamahata> v1driver is deprecated.
15:20:17 <yamahata> When we're confident and openstack CI job is enabled(i.e. voting), v1driver will be removed.
15:20:35 <yamahata> Unfortunately rigth now jobs with v2driver isn't stable as we hoped.
15:21:20 <yamahata> mbuil: does it make sense?
15:21:31 <mbuil> yamahata: Yep, we are finding several problems. I will send a mail to you guys as soon as we are done with our investigation :)
15:21:39 <mbuil> yamahata: yes, thanks a lot
15:22:20 <yamahata> Oh I forgot to mention carbon release.
15:23:06 <yamahata> ODL carbon release was released. and SR1 is planned July 6.
15:23:12 <yamahata> any other announcement?
15:24:05 <yamahata> move on
15:24:06 <yamahata> #topic action items from last meeting
15:24:18 <yamahata> I suppose no major one except patch/bug review
15:24:25 <yamahata> #topic pike/nitrogen planning
15:24:46 <yamahata> anything else other than ODL DDF?
15:25:31 <yamahata> One more thing to share.
15:25:48 <yamahata> netvirt folks said that right now they're testing with carbon + newton.
15:25:56 <yamahata> So they're moving to ocata + carbon.
15:26:32 <yamahata> Nitrogen isn't tested well right now. They're starting to work on ocata + nitrogen.
15:26:51 <yamahata> okay, then patch/bugs
15:26:57 <yamahata> #topic patches/bugs
15:27:10 <yamahata> any patches/bugs?
15:27:22 <rajivk_> yeah
15:27:41 <yamahata> rajivk: which one?
15:28:00 <rajivk_> For LBaaS driver, is their anything that needs to be done except functional?
15:28:22 <rajivk_> Do you see any major problem with LBaaS driver?
15:28:38 <yamahata> Do you mean https://review.openstack.org/#/c/449432/ ?
15:28:58 <rajivk_> yes
15:28:59 <yamahata> So far no except patch review.
15:29:16 <rajivk_> ok
15:29:43 <rajivk_> Can you have a loot at rpc websocket?
15:30:11 <rajivk_> loot ==> look
15:30:15 <yamahata> #link https://review.openstack.org/#/c/470194/
15:30:15 <yamahata> Provide support for RPC calls from ODL to neutron
15:30:31 <rajivk_> yes
15:30:51 <yamahata> The overall direction looks good. I'll review it.
15:31:01 <yamahata> One thing to fix is multiplex.
15:31:10 <rajivk_> Are you going to address comments on rpc specs comment or should i take it?
15:31:37 <yamahata> get_rpc_notification_handler() handles rpc request in serial. It should be multiplexed.
15:32:21 <rajivk_> you mean, i need to use some threads etc?
15:32:47 <yamahata> I'll update rpc spec anyway according to discussion at ODL DDF. It will include comparision with other options.
15:33:06 <yamahata> Not thread. By using xid.
15:33:09 <rajivk_> okay
15:33:26 <rajivk_> ok, i will look into xid and work on it.
15:33:37 <yamahata> do you think if it's easy to add cast support in addition to call?
15:34:00 <rajivk_> I have already added it.
15:34:19 <yamahata> oh cool.
15:34:22 <rajivk_> How can we identify cast or call from ODL?
15:34:42 <rajivk_> I could not see it in YANG model, i mean corresponding parameter.
15:34:44 <yamahata> by the parameter in request message.
15:34:55 <yamahata> Okay, we can update yang model to support cast.
15:35:13 <rajivk_> ok
15:35:41 <yamahata> #action yamahata update yang model for openstack rpc to support cast.
15:35:51 <yamahata> #action yamahata update spec for openstack-rpc
15:36:25 <yamahata> any other patches/bugs?
15:36:36 <rajivk_> I have submitted threadpool patch, it will helpful if you can review at early stage
15:36:47 <yamahata> sure
15:36:47 <rajivk_> #link https://review.openstack.org/#/c/452647/
15:37:21 <rajivk_> and this one as https://review.openstack.org/#/c/460470/
15:37:31 <rajivk_> are you expecting something from this patch?
15:38:01 <rajivk_> I checked APIs but i could not find API responding complete dict required by neutron.
15:38:01 <yamahata> Do you mean 460470?
15:38:09 <rajivk_> yes
15:38:31 <rajivk_> It just responds with the name of supported rules.
15:38:35 <yamahata> ODL neutron northbound will provide the list of supported rules.
15:39:07 <yamahata> neutron-qos.yang qos-rule-types
15:39:14 <rajivk_> yeah, i have done the same. based on the name i provide all the parameters required.
15:39:34 <yamahata> the model may need updated, though because neutron qos api has changed a bit.
15:39:44 <rajivk_> But expectation seems to be something else, Could you please elaborate on it?
15:40:09 <yamahata> What do you mean? I don't get your question?
15:40:41 <yamahata> ODL supports multiple openstack backends. their support level may be different.
15:41:09 <yamahata> Even with same backend, their support may evolve on ODL version.
15:41:21 <rajivk_> for this bug, i am fetching list of supported rules and then updating dict
15:41:44 <rajivk_> >>the direction is to retrieave the supported rule list from ODL. not updating the list.
15:41:53 <rajivk_> what do you mean by above?
15:41:59 <yamahata> As we don't want to keep  supported list in networking-odl, ODL will provide it to networking-odl.
15:42:21 <rajivk_> I am doing the same.
15:42:52 <rajivk_> https://review.openstack.org/#/c/460470/2/networking_odl/qos/qos_driver_v2.py Line 79
15:42:54 <yamahata> Which line in the patch do you mean?
15:43:04 <rajivk_> is it what you mean?
15:43:12 <yamahata> We don't want to keep update the list in networking-odl.
15:43:21 <yamahata> instead ODL provides it to networking-odl.
15:43:55 <rajivk_> by which mechanism?
15:44:00 <yamahata> on neutron startup, networking-odl retrieave it from ODL yang model.
15:44:17 <yamahata> neutron-qos.yang qos-rule-types
15:44:40 <rajivk_> by using rest client?
15:44:46 <yamahata> Yes.
15:45:34 <rajivk_> So during driver initialization, networking-odl creates a rest call and update supported dict.
15:45:41 <rajivk_> is my understanding correct?
15:45:43 <yamahata> Yes.
15:46:40 <rajivk_> ok, Could you please leave a comment? I think, i am doing the same, comment on the part, which is not correct.
15:47:08 <yamahata> wait. I'm looking at ine 77.
15:47:20 <yamahata> Oh, the patch is 2. I was looking PS 1.
15:47:52 <yamahata> Anyway I'll review the patch
15:48:00 <yamahata> #action yamahata review https://review.openstack.org/#/c/460470/2/networking_odl/qos/qos_driver_v2.py
15:48:48 <rajivk_> I am trying https://review.openstack.org/#/c/464952/. there seems to be problem with postgres Enum type server_default values
15:49:01 <rajivk_> did you face it ever before?
15:49:50 <yamahata> No. to be honest, I tested it only with mysql.
15:49:59 <yamahata> what error are you seeing?
15:50:23 <rajivk_> I tried a lot of things, in some cases default is not supported
15:50:38 <rajivk_> the last is programming exception.
15:50:49 <rajivk_> I will look into it.
15:52:10 <rajivk_> Are you able to perform any other operation with floating IPs except ssh.
15:52:29 <yamahata> No. ssh fails with nitrogen
15:52:38 <rajivk_> What about ping>?
15:52:48 <yamahata> I talked it with netvirt. and the patch was came up.
15:53:06 <yamahata> https://git.opendaylight.org/gerrit/#/c/58176/
15:53:12 <yamahata> I haven't tested it yet, though.
15:53:24 <rajivk_> was it broken by netvirt?
15:53:27 <yamahata> manjeets: will test it.
15:53:40 <yamahata> at the moment it's the theory.
15:54:04 <rajivk_> Today you posted a patch, it is passing
15:54:16 <yamahata> oh.
15:54:21 <rajivk_> https://review.openstack.org/#/c/469866/
15:54:37 <rajivk_> I mean this one, did you find root cause of the problem?
15:54:48 <medraz> hello
15:54:52 <medraz> can you help me
15:55:01 <yamahata> most tempest jobs are failing.
15:55:15 <yamahata> They are non-voting,
15:55:41 <rajivk_> ok i got it.
15:55:46 <yamahata> medraz: can you please wait for a while? we're having weekly irc meeting.
15:56:03 <rajivk_> Anything you want me to take on high priority any bug or BPs?
15:56:33 <yamahata> other high priority one is status update stuff.
15:56:46 <medraz> when I intergrate opendaylight with openstack I have a probleme
15:56:59 <yamahata> anything else on patches/bugs?
15:57:11 <rajivk_> yamahata, can you assign me some from status update?
15:57:29 <yamahata> There are several patches. So please review them.
15:57:38 <rajivk_> ok, i will.
15:57:41 <medraz> openstack instance does not start
15:58:06 <rajivk_> that's all from my side.
15:58:26 <yamahata> move on
15:58:30 <yamahata> #topic open mike
15:58:40 <medraz> but when I use openstack only I dont have probleme
15:58:56 <yamahata> anything else to discuss?
15:59:44 <jhershbe> hey
15:59:58 <jhershbe> we can discuss  port status patches
16:00:04 <yamahata> jhershbe: hi again. you're on stage.
16:00:58 <jhershbe> so I had a feeling that perhaps those patches are slightly stalled due to the async nature of what I put in for feature fetch not being fully understood...
16:01:30 <jhershbe> basically, from my perspective, it really looks to me like these patches are ready to move fwd and I wanted to ask if there was something I could do to help that happen
16:02:34 <yamahata> Sure, I'm keeping reviewing the patches.
16:02:40 <jhershbe> ok
16:02:57 <jhershbe> do you want me to explain more about the threading/process model? It's a little tricky
16:03:00 <yamahata> And also can you please add release notes. several changes would change cloud admin visiable behaviour.
16:03:17 <yamahata> https://docs.openstack.org/developer/reno/
16:03:32 <yamahata> It's worthwhile for release note.
16:03:41 <jhershbe> ok. will look at adding a release note tomorrow
16:03:54 <yamahata> On startup, neutron starts as single process,
16:04:16 <yamahata> then initialise plugins. including ml2 driver and mech drivers etc.
16:04:27 <jhershbe> yes
16:04:35 <yamahata> After those initialization, neutron workers will be forked.
16:04:40 <jhershbe> features are *not* retrieved at that point
16:04:49 <jhershbe> here's the sequence:
16:04:58 <jhershbe> 1. mech driver initialize is called.
16:05:27 <jhershbe> 2. sub processes are forked and each one launches a feature retrieving thread
16:05:46 <jhershbe> 3. after all sub-procs are forked, the main proc spawns the feature retrieve thread
16:06:21 <yamahata> Why can't you retrieave features at step 1?
16:07:17 <jhershbe> because I don't know when it will complete. I don't want to fork the sub-procs with that thread running in the background in an indetermined state. Instead, I do it in the most deterministic way possible
16:07:42 <manjeets> thanks yamahata i'll test this patch
16:08:12 <yamahata> we can retrieve feature in main thread. we don't have to do it backgroundly.
16:08:25 <rajivk_> why 2 and step 3 are doing the same thing
16:08:50 <jhershbe> we can not retrieve it in the main thread because we do not know how long it will take until ODL responds.
16:09:04 <jhershbe> we do not want to shut down the main thread while we poll ODL
16:09:04 <rajivk_> main process can do it in one thread and it can be shared amond all subprocess
16:09:24 <rajivk_> their must be possible ways to share variables amond process
16:09:36 <yamahata> without retrieving features, neutron server can't work reliable. So it makes sense for neutron to wait for ODL.
16:09:40 <jhershbe> why not just retrieve it separately in each process?
16:09:59 <rajivk_> multiprocessing supports it through intializers
16:10:26 <jhershbe> yamahata, the whole point of features is that they can be on or off. As such, neutron server can and should be able to function without hte features retrieved. Are you saying we should not accept API calls until features are retrieved?
16:10:28 <rajivk_> If it is possible to fetch once and use among all of them is always a better option.
16:10:28 <yamahata> networking-odl needs features to function properly.
16:10:52 <jhershbe> rajivk, ODL is not necesarilly running
16:10:55 <yamahata> jhershbe: yes.
16:11:18 <jhershbe> ok, yamahata, as such, it needs to run in a separate thread, correct?
16:11:29 <jhershbe> otherwise it blocks the main thread
16:11:37 <yamahata> No. we can just wait for ODL to come up.
16:11:56 <jhershbe> yamahata, please explain why that is better?
16:11:57 <yamahata> Yes, we can block main thread.
16:12:08 <jhershbe> I specifically asked you that a while back and you said not to.
16:12:27 <yamahata> Sorry for misunderstanding.
16:12:28 <jhershbe> I went ahead and implemented this whole thing because of that...it's better this way
16:12:48 <yamahata> We can just block in mainthread in ml2 driver initialization.
16:12:58 <jhershbe> includng callbacks for initialization. I really do not understand why it is that it is *better* to block the main thread while this initialization happens
16:13:46 <yamahata> the code will be simpler, we don't have to worry about race condition.
16:13:55 <jhershbe> there is not race condition now
16:14:52 <yamahata> If we retrieve features backgroundly and allow neutron server to accept request from user, features can change asynchronously at any point.
16:15:02 <jhershbe> yamahata, not true
16:15:07 <jhershbe> please allow me to explain
16:15:18 <yamahata> sure. please enlighten me.
16:16:02 <jhershbe> of course features can change but the whole point of features, as I stated above, is that neutron will know how to work with them on or off...
16:16:52 <jhershbe> ...as such, so long as the change is atomic within a process, it should be OK. That is how I coded it, first the initialization callbacks are called *before* the features are made available to the running processes.
16:17:11 <yamahata> The call to has_feature is okay.
16:17:27 <jhershbe> huh?
16:17:31 <jhershbe> not understanding
16:17:33 <yamahata> In processing request form user, has_feature can be called many times.
16:18:01 <yamahata> the result of calling has-feature must be same.
16:18:16 <jhershbe> that is not the case with port status. If there is a feature like that it would need to check whether the initialization occurred.
16:18:31 <jhershbe> once init occurred, it can not change
16:18:42 <yamahata> port status case may be okay. but in general, we can not tell future.
16:18:43 <jhershbe> but again, for port status there is no need to check that (for now)
16:18:58 <yamahata> How can you guarantee that has-future usage pattern.
16:19:00 <jhershbe> and in the future there is the option to check whether there was an init
16:19:31 <yamahata> On the other hand, we can just simply block at startup.
16:19:48 <yamahata> the code will be simpler and we don't have to worry such thing.
16:19:53 <jhershbe> a) I don't think it is necessary to guarantee that at this point and b) since some features will be "atomic" like port status I don't think we should gurantee it
16:20:12 <jhershbe> yes, but you will have to worry about the fact that if ODL is unreachable neutron will not accept API calls
16:20:41 <yamahata> Right, we have to care about ODL reachability.
16:20:55 <jhershbe> you prefer it that way
16:20:56 <jhershbe> ?
16:20:58 <yamahata> We can just timeout and abort. warning admin.
16:21:32 <jhershbe> what made you change your mind? I spent A LOT of time rebasing and getting this all to work on your suggestions ;-)
16:22:04 <yamahata> To be honest, I'm sure when I suggest so. anyway sorry for misundending you.
16:22:33 <yamahata> sorry. I'm not sure when I said so.
16:22:57 * yamahata mistyping.
16:23:29 <jhershbe> it was you and yamamoto, in responses and conversations following some comments of his. I specifically asked. Doesn't matter at this point. I will consult wiht Mike and Livnat and get back to you
16:24:36 <yamahata> Okay.
16:24:44 <jhershbe> talk to you later
16:24:52 <yamahata> sure. later
16:25:04 <yamahata> #topic cookies
16:25:08 <yamahata> #endmeeting