16:03:21 <yamahata> #startmeeting neutron_northbound
16:03:21 <odl_meetbot> Meeting started Mon Jan 23 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:32 <yamahata> #chair vthapar
16:03:32 <odl_meetbot> Current chairs: vthapar yamahata
16:04:33 <yamahata> #topic agenda bashing and roll call
16:04:36 <yamahata> #info yamahata
16:04:40 <vthapar> #info vthapar
16:04:46 <yamahata> #link https://wiki.opendaylight.org/view/NeutronNorthbound:Meetings
16:05:17 <yamahata> any other topics in addition to usual topic?
16:06:21 <vthapar> I'd like to discuss trunk drivers, not much other than that
16:06:31 <yamahata> okay. let's move on
16:06:36 <yamahata> #topic Announcements
16:06:43 <yamahata> odl M3 offset 1 is reached.
16:07:02 <yamahata> But after the report, I've got some update. So I'm going to update M3 report.
16:07:09 <yamahata> #action yamahata update M3 report.
16:07:41 <yamahata> the schedule of cutting openstack stable/ocata was announced.
16:08:21 <yamahata> For netwokring-odl the hard deadline is 16 Feb.
16:08:43 <yamahata> So the team probably upload the patch to cut it around Feb 9.
16:08:53 <yamahata> 1 week before the hard deadline would be reasonable.
16:09:16 <vthapar> by when we need all patches to be in? I believe need some time to have all tests stable too, right?
16:09:16 <yamahata> any other announcement?
16:09:47 <yamahata> Yes.
16:10:09 <yamahata> Given time needed for test, we really need to hurry.
16:10:36 <yamahata> ideally as soon as possible.
16:10:59 <vthapar> ok.
16:11:21 <yamahata> If we're not very confident with its stability, we can announce the feature as experimental.
16:11:28 <yamahata> in networking-odl.
16:11:56 <yamahata> Especially trunk api in networking-odl would be mark experimental.
16:12:19 <vthapar> okay. was about to ask that as backend implementation of trunk will be coming bit later.
16:12:39 <vthapar> I beleive stability also includes ODL NN and netvirt, right?
16:12:48 <yamahata> right.
16:13:32 <yamahata> tempest scenario test case would be wanted.
16:13:39 <vthapar> okay, would be good to have criteria documented for experimental or stable. I think stable means tempest passing.
16:13:46 <vthapar> agree
16:14:51 <yamahata> move on
16:15:12 <yamahata> #topic action items from last meeting
16:15:28 <yamahata> yamahata review patches.
16:15:47 <yamahata> I'll keep reviewing patches to include remaining patches.
16:16:06 <yamahata> #topic carbon planning
16:16:34 <yamahata> As I mentioned a bit, for carbon hostconfig patches for ovs/vpp will be included.
16:16:40 <yamahata> So I'll update M3 report.
16:17:13 <yamahata> and trunk api and yang model update(e.g. project-id) will be included
16:17:22 <yamahata> #topic neutron stadium effort
16:17:47 <yamahata> Now hopefully grenade ci is passing.
16:18:21 <yamahata> #topic migrating to new features
16:18:33 <yamahata> Now Mike introduced tempest tests with v2driver.
16:18:46 <yamahata> but it seems a bit unstable. need to keep eyes on it.
16:19:04 <yamahata> new netvirt. yamahata will update patch for project-config
16:19:17 <yamahata> #topic patches/bugs
16:19:32 <yamahata> vthapar: you have a stage?
16:19:50 <yamahata> which patches do you want to discuss?
16:19:53 <vthapar> #link https://review.openstack.org/421895
16:20:21 <vthapar> it is more or less done from my side. I added more dependency validations and got good coverage on trunk dependency code.
16:20:37 <yamahata> great.
16:20:46 <yamahata> #action yamahata review https://review.openstack.org/421895
16:21:01 <vthapar> #link https://review.openstack.org/422421
16:21:24 <yamahata> #action yamahata review https://review.openstack.org/422421
16:21:26 <vthapar> this is in shape to review now, functional tests are TODO.
16:21:37 <vthapar> #link https://review.openstack.org/424064
16:21:53 <vthapar> this one is still WiP.
16:22:03 <yamahata> Cool. gbpvpn v2driver is also coming.
16:22:06 <vthapar> so can probably hold off for now. should be ready in day or two.
16:22:14 <yamahata> sure.
16:22:31 <vthapar> talked to bgpvpn folks and they're okay to retain v1 in their tree till Pike release. so we're only adding v2 to n-odl
16:22:41 <yamahata> got it.
16:23:05 <yamahata> btw when are you going to update documentation?
16:23:10 <yamahata> Maybe netvirt one.
16:23:25 <vthapar> I'll do, let me know which ones need to be updated.
16:23:26 <yamahata> People may want to use those three functions after networking-odl ocata release.
16:23:42 <yamahata> So the documents would be needed before carbon release.
16:23:54 <vthapar> okay, you mean the ODL+OpenStack document, right?
16:23:59 <yamahata> Yes.
16:24:08 <vthapar> I'll update that. am the doc lead for netvirt :)
16:24:22 <vthapar> but need things working once and test them end to end.
16:24:27 <yamahata> I'd like to have a link so that we can point to it.
16:24:30 <vthapar> probably before M4.
16:24:35 <vthapar> okay.
16:24:37 <yamahata> Yes, it's not urgent.
16:24:51 <vthapar> link to general ODL+OpenStack or trunk etc. specific?
16:25:10 <yamahata> ODL + OpenStack.
16:25:25 <vthapar> #link http://docs.opendaylight.org/en/latest/opendaylight-with-openstack/index.html
16:25:38 <vthapar> #link http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/openstack-guide/index.html
16:25:55 <vthapar> first one links to second one
16:26:31 <yamahata> thanks for the link
16:27:03 <yamahata> any other patches/bugs to discuss?
16:27:25 <yamahata> #link https://git.opendaylight.org/gerrit/#/c/50615/ Add support for Openstack Neutron Trunkport APIs
16:27:42 <yamahata> I'm going to merge it tomorrow after netvirt meeting.
16:27:46 <vthapar> cool!
16:28:04 <vthapar> I thin Ariel already gave +1.
16:28:10 <vthapar> ^think
16:28:25 <yamahata> I hoped more netvirt guys review. but it's okay with me.
16:29:10 <yamahata> anything else?
16:29:31 <yamahata> #topic Open Mike
16:29:36 <vthapar> wanted to discuss couple open points for trunk patch in n-odl, but can take it up in open mike
16:30:01 <yamahata> okay, you're on the stage.
16:30:22 <vthapar> one issue I faced when testing this was that if I enable ODL_L3 in devstack, it would overwrite service_plugins entry.
16:30:41 <vthapar> I was adding trunk as post-config in NEUTRNO_CONF
16:31:03 <vthapar> I think need some code in devstack to allow it... I looked but couldn't figure out where.
16:32:00 * yamahata digging into devstack
16:33:44 <vthapar> maybe we could look into it later, other point was, trunk status. it supports setting status to ERROR, DEGRADED etc. I think we could update it based on status in journal... something to consider for future.
16:34:16 <vthapar> for now I set it active once we do postcommit. on v1 am setting to degraded if sendjson throws exception.
16:34:18 <yamahata> Hmm, probably neutron_service_plugin_class_add
16:34:46 <vthapar> are we planning to handle ODL faiures in, say, netvirt?
16:35:09 <vthapar> I guess a generic comment for all resources that support state, not just trunks.
16:35:47 <yamahata> Yes. I'm planning that by using websocket, networking-odl receives the notification from ODL on status.
16:35:54 <yamahata> then status will be updated.
16:36:01 <vthapar> aha, that would be helpful then :)
16:36:21 <yamahata> In trunk API case, it's a bit different. If sendjson fails, we'd like to update status to DEGRADED.
16:36:35 <vthapar> does journal capture suchinformation?
16:36:49 <vthapar> what does it do if sendjson fails?
16:36:52 <yamahata> With the current implementation, no.
16:37:07 <yamahata> Nothing will happend. We'll retry the journal entry.
16:37:20 <vthapar> okay.
16:37:34 <vthapar> other point I wanted to bring up was filters when sending json.
16:37:58 <yamahata> what issue do you have with filters?
16:37:59 <vthapar> e.g. trunk_details extension decorates trunk's parent port with infomation about subports.
16:38:10 <vthapar> we don't really need to send all that json as part of port_update.
16:38:26 <yamahata> Right.
16:38:27 <vthapar> not that simply creating subports does't send it, it comes in any subsequent port updates.
16:38:38 <vthapar> more of an optimization, to reduce datain journal and sent to ODL
16:38:42 <vthapar> ^data in
16:38:54 <yamahata> Yes filters can be used for that purpose.
16:39:06 <vthapar> also noticed getting created-at etc. values for most objects but don't think we're using them.
16:39:14 <yamahata> In case subport, we can drops trunk-details from port.
16:39:25 <vthapar> yeah.
16:39:37 * vthapar getting link to dump
16:40:22 <yamahata> Feel free to send a patch to update filters for optimisation.
16:40:27 <vthapar> #link https://etherpad.openstack.org/p/trunk-api-dump-newton
16:40:36 <vthapar> line 1756, search for trunk_details.
16:40:42 <vthapar> it adds following to port:
16:41:01 <vthapar> "trunk_details": {"trunk_id": "bc587c4c-de31-42b1-89c3-809add88c9b3", "sub_ports": [{"segmentation_id": 101, "port_id": "75e366aa-51b6-4ec8-9695-739c465377f7", "segmentation_type": "vlan", "mac_address": "fa:16:3e:44:c8:d9"}, {"segmentation_id": 102, "port_id": "e12f8356-ff66-4948-979f-9dedb63ee299", "segmentation_type": "vlan", "mac_address": "fa:16:3e:da:bb:a0"}]}
16:41:41 <vthapar> mac address is what it gets from subport's neutron port. rest are part of subport itself.
16:42:03 <vthapar> we could leverage it for optimization later, but for that we'll need yang changes.
16:42:09 <yamahata> As trunk_details isn't needed, it can be filters out.
16:42:19 <vthapar> I'd rather go with what we have and include it if we think it will help.
16:42:26 <yamahata> Right. ODL NN ignores unknown fields.
16:42:30 <vthapar> do we have framework for filtering? or need to add it?
16:42:44 <vthapar> yeah, so why store in journal or send if not gonna use it. can be perf issue at scale
16:43:02 <yamahata> trunk_details can just be added.
16:43:31 <yamahata> filters._filter_port_update
16:43:49 <yamahata> we can add 'trunk_detail' to the argument of try_del.
16:43:53 <vthapar> okay, will add that in subsequent patch, depending on your review comments.
16:44:45 <vthapar> is it possible to let plugin know we don't support trunk_details extension?
16:45:16 <vthapar> I think for most ml2 extensions drivers can pick and choose, right? might be better way.
16:46:24 <yamahata> Right. Do you mean plugin=ml2 plugin?
16:46:37 <yamahata> In filter code, we can unconditionally remove trunk_detail.
16:47:03 <yamahata> If trunk_details isn't there, it's noop
16:47:27 <vthapar> okay, will go with that. I was wondering if some way for trunk driver to tell trunk plugin it doesn't support trunk_details. couldn't find any.
16:47:44 <yamahata> In code, we can utilise neutron.manager to check if which service plugins are loaded.
16:48:14 <vthapar> hmmm... will go with filtering for now, will be easier to get it back if we need tomorrow
16:49:37 <yamahata> In that case, we can check if trunk-details extension is loaded or not.
16:49:54 <yamahata> Eventually what do you want to do?
16:50:11 <vthapar> I saw plugin code, it is always loaded, hard coded.
16:50:14 <yamahata> by knowing if trunk-details is loaded or not.
16:50:25 <vthapar> class TrunkPlugin(service_base.ServicePluginBase,
16:50:25 <vthapar> common_db_mixin.CommonDbMixin):
16:50:25 <vthapar> supported_extension_aliases = ["trunk", "trunk-details"]
16:50:51 <vthapar> I think better just filter if absence means noop.
16:52:03 <yamahata> Are you worry about performance?
16:52:49 <vthapar> yes. perf at scale due to duplicated information which we'll not use.
16:53:14 <vthapar> mainly on journal and rest calls.
16:53:43 <yamahata> I see. the filter code would be essentially something like port_dict.pop("trunk-detaiks", None).
16:54:06 <yamahata> I expect unconditional dict.pop would be acceptable.
16:54:14 <vthapar> filtering will be done before adding to journal?
16:55:08 <yamahata> Right now it's after journal right before sending json.
16:55:31 <yamahata> Hmm, maybe it might better do it before journaling, though.
16:55:37 <vthapar> okay, would be good to do it before adding. will help with journal perf.
16:55:44 <yamahata> We haven't measured performance difference, though.
16:56:05 <vthapar> well, we know it *will* be better with filtering before than after :)
16:56:59 <yamahata> Yeah. Originally filter is introduced for bug workaround and etc. not for performance.
16:57:23 <yamahata> It won't be difficult to change where filter is done.
16:58:27 <yamahata> time is running out.
16:58:36 <yamahata> any other topics to discuss?
16:58:45 <vthapar> none. thank you!
16:58:55 <yamahata> thank you every one
16:59:03 <yamahata> #topic cookies
16:59:08 <yamahata> #endmeeting