16:01:02 <mestery> #startmeeting networking_ml2
16:01:03 <openstack> Meeting started Wed Dec  4 16:01:02 2013 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:06 <openstack> The meeting name has been set to 'networking_ml2'
16:01:07 <Sukhdev> Hello
16:01:15 <asadoughi> hi
16:01:37 <mestery> #link https://wiki.openstack.org/wiki/Meetings/ML2 Agenda
16:01:54 <mestery> #topic Action Items From Last Week
16:02:08 <mestery> First item from last week: multi-node devstack gate testing
16:02:16 <mestery> I attended the infra meeting last week
16:02:22 <mestery> There is no multi-node gate testing done now.
16:02:30 <mestery> So, we will be blazing a new path here.
16:02:43 <mestery> I will spend some time on this before next week's meeting.
16:02:46 <mestery> Any questions?
16:03:44 <mestery> Next action item is for asomya.
16:03:57 <mestery> asomya: Review the TypeDriver patch.
16:04:06 <mestery> asomya: hi
16:04:12 <asomya> hi
16:04:13 <mestery> asomya: Did you review the TypeDriver patch?
16:04:19 <mestery> We are reviewing your action item from the last meeting.
16:04:32 <asomya> Yes, i posted a couple of inline question and a general one explaining my proposal
16:05:07 <mestery> asomya: OK, thanks. We can cover this in more detail later, wanted to make sure you had reviewed it.
16:05:23 <mestery> #topic Development Issues
16:05:28 <mestery> rkukura rcurran: Both here?
16:05:37 <rkukura> I am
16:05:38 <rcurran> yup
16:05:55 <mestery> rcurran: This is about the VLAN availability during delete_port_postcommit()
16:05:59 <mestery> And the thread we've had around that.
16:06:08 <mestery> Wanted to discuss this with the broader team in the meeting.
16:06:13 <rkukura> Really the bound_segment being available
16:06:21 <mestery> rkukura: Yes
16:06:56 <rcurran> do you want me to state what i found?
16:07:26 <mestery> rcurran: Yes, please do.
16:07:31 <rcurran> that is the issue in a nutshell
16:07:46 <rcurran> i'm trying to make better use of the pre/postcommit() methods
16:08:14 <rcurran> found out that on delete port the unbinding is done before the postcommit
16:08:26 <rcurran> i need info in postcommit for nexus programming
16:08:40 <matrohon> we had the same issue
16:08:46 <matrohon> for l2pop
16:08:51 <mestery> matrohon: How did you solve this?
16:08:53 <rcurran> general issue seems to be that if in a create function you call subcreateA,B,C
16:09:12 <rcurran> that on deletes the calls should be made in the reverse order C,B,A
16:09:19 <rkukura> I'd argue unbind_segment() should have pre and post commit calls
16:09:20 <rcurran> just a thought
16:09:23 <mestery> rcurran: +1 to that.
16:09:34 <matrohon> we have store locally the data we nedded during pre-commit, and used it during post-commit
16:09:35 <mestery> rkukura: Thoughts on the ordering issue rcurren mentioned?
16:10:02 <rkukura> not sure I understand why that matters right now - there is only one bound segment belonging to one MechanismDriver
16:10:17 <Sukhdev> I felt the delete methods were ordered wrong - when I worked on it as well
16:10:49 <rkukura> I'm OK with reversing the order for deletes relative to creates, but don't see how that relates to the original issue
16:10:58 <mestery> Conceptually it makes sense to tear things down in the exact reverse order as they were put up.
16:10:58 <rcurran> it fixes it
16:11:10 <rkukura> how does it fix it?
16:11:40 <rcurran> forgetting about the naming issue for a moment, delete_port_postcommit() is called before the db trans code
16:11:59 <rkukura> Oh, you mean reversing the pre/post?
16:12:10 <rcurran> naming issues aside, yes
16:12:16 <rkukura> thought you meant calling the list of MDs in the reverse order
16:12:20 <rcurran> i never liked those names :-)
16:12:28 <rcurran> no
16:13:10 <rkukura> Still, I think port_unbind() needs to be handled consistently/correctly whether part of delete_port() or otherwise
16:13:53 <rkukura> So if an MD needs to do something outside a transaction, we need that to work as part of port_unbind()
16:13:59 <rcurran> yeah, it probably should have a pre/post type style to be in line w/ the other methods
16:14:19 <mestery> rkukura rcurran: I agree.
16:15:14 <matrohon> what if the binding was stored in the port context, in orig_context
16:15:26 <rkukura> How about we move the private email discussion to openstack_dev, and try to come to a plan
16:16:01 <rcurran> ok by me
16:16:02 <mestery> rkukura: Lets do it.
16:16:05 <matrohon> rkukura : fine, put me in this discussion
16:16:11 <mestery> Who wants this action item?
16:16:35 <mestery> #action rcurran to move this discussion to openstack-dev
16:16:37 <rkukura> I can take it
16:16:41 <mestery> rcurran: I gave it to you :)
16:16:55 <rcurran> sorry, was looking at something else ... ok
16:17:03 <mestery> OK, moving on to the next item on the agenda
16:17:03 <rkukura> last email was from rcuran, so I can just reply adding the list
16:17:10 <mestery> rkukura: OK, makes sense.
16:17:12 <rcurran> yes, bob please do
16:17:14 <mestery> #undo
16:17:14 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x269f890>
16:17:23 <rcurran> cc matrohon too
16:17:24 <mestery> #action rkukura to continue discussion on openstack-dev
16:17:38 <matrohon> rcurran : thanks
16:17:46 <mestery> #topic Testing
16:18:07 <mestery> So, there are 4 items in this area on the agenda.
16:18:16 <mestery> Lets start with unit tests, which may be the easiest.
16:18:32 <mestery> At the last meeting, we decided we should possibly add more unit test coverage for ML2.
16:18:39 <mestery> Does anyone want to take this action item and look into this?
16:18:45 <rkukura> has anyone checked the coverage?
16:18:52 <mestery> I don't think so, no.
16:18:55 <mestery> That would be a good first step.
16:19:03 <Sukhdev> I looked into the port testing
16:19:24 <Sukhdev> and notice that it does not work well for ML2 drivers/context
16:19:36 <mestery> Sukhdev: Unit testing?
16:19:47 <mestery> Sukhdev: Or is that functional/tempest testing?
16:20:00 <Sukhdev> Oh - my bad - sorry - I was talking about tempest test
16:20:22 <rkukura> I'm pretty sure the RPC methods in the server need real unit testing
16:20:23 <mestery> Sukhdev: No worries.
16:20:29 <mestery> rkukura: Agreed.
16:20:37 <mestery> OK, if no one is volunteering, I'll work offline to find someone to cover this.
16:20:45 <mestery> This being the unit test coverage.
16:20:57 <mestery> #action mestery to find a volunteer to verify and possibly expand ML2 unit test coverage.
16:21:15 <mestery> The next item is multi-node devstack based gate testing.
16:21:29 <mestery> We briefly touched on this earlier. I need to research this more and come up with a plan for this.
16:21:35 <rkukura> mestery: Can this be combined with the scenarios in the next item?
16:21:47 <mestery> rkukura: I think that seems reasonable, yes.
16:21:53 <rudrarugge> hi - is this the policy meeting. sorry joining late
16:22:03 <roaet> rudrarugge: ml2 subteam meeting
16:22:04 <mestery> rudrarugge: Nope, ML2 meeting
16:22:11 <rudrarugge> ok
16:22:24 <rkukura> So multi-node tempest tests run for various config scenarios?
16:22:32 <mestery> rkukura: Are you saying the multi-node stuff shoudl just be tempest tests?
16:22:37 <mestery> rkukura: I think so, yes.
16:22:59 <mestery> So, I think you're right rkukura, this will cover both items.
16:23:05 <rkukura> I'd hope we could reuse as much of what exists as possible
16:23:47 <mestery> rkukura: Agreed.
16:24:00 <mestery> rkukura: But this will require whatever is using tempest to spin up multiple VMs.
16:24:09 <mestery> I may need to look at this closer if I'm not understanding something here.
16:25:10 <rkukura> I don't know the details, but couldn't something do a multi-node devstack deployment and then run tempest in one of the nodes?
16:25:24 <mestery> rkukura: I think that's the idea, yes, but that doesn't exist today. :)
16:25:39 <mestery> The tripleo folks are looking at something similar, according to the infra folks.
16:25:45 <Sukhdev> Are there any tempest tests for multi-node setup - did I miss anything....I did not see any
16:25:46 <mestery> So we may be able to combine efforts.
16:25:55 <mestery> Sukhdev: There are none.
16:25:57 <mestery> We need to add those.
16:26:29 <rkukura> Wouldn't just running the existing tempest tests in a multi-node deployment add significant value?
16:26:43 <mestery> rkukura: Yes, I think that's a good start.
16:27:18 <Sukhdev> rkukura - only if you combine them with nova - otherwise no
16:27:27 <rkukura> Then some addition tests could be added to tempest to specifically exercise cross-node interactions
16:27:54 <mestery> Wait, if you run Tempest against a multi-node openstack, it will be default be using multiple nodes, right?
16:28:00 <mestery> As long as it spins up multiple VMs I guess?
16:28:03 <mestery> What am I missing here?
16:28:07 <rkukura> I was assuming these tempest tests would include nova
16:28:46 <Sukhdev> there are nova tests and neutron test - I did not see one invoking other
16:29:20 <mestery> The neutron tests have to spinup VMs for testing, right? They would implicitly be using nova.
16:29:30 <Sukhdev> when you run neutron port test - they have no clue about nova tests - hence, there is no host information - and hence, you can test networks across multi-nodes
16:29:31 <rkukura> don't tempest smoke tests involve both nova and neutron?
16:30:14 <mestery> I thought they did.
16:30:26 <Sukhdev> they do them serially - based upon what i saw
16:30:56 <matrohon> https://github.com/openstack/tempest/blob/master/tempest/scenario/test_network_basic_ops.py
16:31:17 <matrohon> this smoke test creat servers and neutron networks
16:31:31 <rkukura> matrohon: right
16:31:38 <mestery> Yes, exactly, the neutron tests make use of nova implicitly.
16:32:31 <rkukura> Sukhdev: Of course there are also tempest tests for neutron that don't involve nova
16:32:54 <Sukhdev> I was looking at the API tests
16:33:11 <Sukhdev> they do not involve Nova tests
16:33:48 <rkukura> so not sure if running all those multi-node adds much, but it shouldn't hurt, and might expose issue
16:33:51 <Sukhdev> https://github.com/openstack/tempest/blob/master/tempest/api/network/test_networks.py
16:34:09 <mestery> API is different than scenario tests, now I understand the gap here Sukhdev.
16:34:54 <rkukura> so what kind of base multi-node deployment scenario would we start with?
16:35:13 <rkukura> Maybe one node for controller/network/tempest and two compute nodes?
16:35:15 <mestery> rkukura: I think just running the existing scenario tests against a multi-node ML2 setup would be the best place to start, right?
16:35:21 <mestery> rkukura: Yes
16:35:34 <matrohon> rkukura: fine
16:36:05 <rkukura> Then we could add/modify some test(s) to force VMs onto different compute nodes, right?
16:36:15 <matrohon> rkukura: yes
16:36:23 <mestery> Yes, that makes sense.
16:36:39 <mestery> So, I think I'll write this up in an etherpad before next week's meeting, does that sound good?
16:36:42 <rkukura> And could this serve as the template for 3rd party external driver/plugin testing?
16:36:50 <mestery> rkukura: Yes, even better!
16:36:58 * mestery likes the slick segway rkukura just did there.
16:37:07 <mestery> Which brings us to our next topic ...
16:37:10 <Sukhdev> mestery: that is a great idea
16:37:21 <matrohon> rkukura: great
16:37:23 <mestery> Vendora based tempest testing for MechanismDrivers
16:37:40 <mestery> #action mestery to start etherpad for multi-node ML2 tempest testing and share with ML2 subteam
16:37:52 <mestery> So, this really applies to more than just ML2, but lets start here.
16:38:04 <mestery> All 3rd party testing requirements are effectively the same.
16:38:18 <mestery> So, I was thinking we should share the knowledge on setting this up so everyone doesn't have to reinvent the wheel.
16:38:26 <mestery> Makes sense?
16:38:35 <Sukhdev> excellent idea
16:39:03 <mestery> I think the basic idea is this:
16:39:20 <mestery> Each 3rd party plugin/MD needs to run the existing Tempest tests when code changes in their plugin or ML2 MD.
16:39:36 <mestery> For this, I think the best way to proceed is to have a Jenkins instance running which reads the gerrit stream and kicks off the tempest tests.
16:40:17 <Sukhdev_> sorry - my connection dropped - back again
16:40:27 <mestery> Sukhdev_: No worries.
16:40:44 <rkukura> mestery: Does this trigger just on merges or also when patches are submitted/approved?
16:40:54 <mestery> When patches are submitted.
16:41:08 <mestery> Because the 3rd party testing needs to vote +1/-1 as well
16:41:19 <rkukura> that's what I hoped
16:41:57 <mestery> OK, I can start an etherpad for this as well to combine information.
16:42:12 <mestery> I was also thinking perhaps a separate meeting next week would be good for people, maybe over WebEx?
16:42:14 <mestery> Thoughts?
16:42:25 <Sukhdev_> So, does there exist anything which we can leverage?
16:42:48 <mestery> Sukhdev_: Yes, there is a jenkins plugin which reads gerrit streams already.
16:42:53 <Sukhdev_> I started to look into writing my own scripts and realized, it will be a lot of work
16:42:53 <rkukura> Is this meeting specifically on multi-node testing and/or 3rd party testing?
16:42:55 <mestery> This is the type of info I hope to share with everyone.
16:43:10 <mestery> I think we should combine the two rkukura.
16:43:21 <mestery> Because 3rd party testing will almost certainly need multi-node testing as well.
16:44:21 <mestery> #action mestery to organize meeting around multi-node tempest testing and 3rd party testing for next week.
16:44:26 <rkukura> and is better than or!
16:44:43 <mestery> :)
16:44:48 <mestery> Anything else on testing for now?
16:45:07 <ZangMingJie> We are also going to deploy multi-node test, maybe we can share idea
16:45:21 <rkukura> we didn't really discuss scenarios to test internally
16:45:44 <mestery> ZangMingJie: Awesome!
16:45:51 <mestery> rkukura: Good point, shall we do that now?
16:47:10 <rkukura> we should leave some time for the TypeDriver discussion
16:47:21 <mestery> Good point, lets move on.
16:47:35 <mestery> We can continue the testing scenario discussion on the ML and in the meeting next week.
16:47:39 <mestery> #topic TypeDriver discussion
16:47:56 <mestery> Per the start of the meeting, asomya has given some comment on ZangMingJie's patch.
16:48:03 <mestery> Anyone else have comments?
16:48:07 <rkukura> I've started reviewing the current patch
16:48:54 <mestery> rkukura: Any high level thoughts at this point?
16:49:04 <rkukura> I like the concept, but will have a few issues on the implementation
16:49:51 <rkukura> From an API perspective, this really forces the move from provider extension to multiprovider extension
16:50:09 <mestery> I think that was what ZangMingJie was intending, right?
16:50:20 <mestery> #link https://review.openstack.org/#/c/37893/ TypeDriver review
16:50:59 <ZangMingJie> Yes, I have posted my opinion to openstack-dev list, IMO we should move to multiprovider extension and abondon provider ext
16:51:18 <rkukura> Didn't see a thread on this, but will look for it
16:52:07 <ZangMingJie> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021117.html
16:52:18 <rkukura> Seems we should be able to maintain provider extension compatibility when only a single segment with then "standard" attributes is involved
16:52:40 <mestery> Agreed.
16:53:16 <ZangMingJie> on API level or neutronclient level ?
16:53:19 <rkukura> I'd like to look carefully at how the segment validation/reservation/allocation stuff is handled in the patch - I have a bit of concern there, but need to look closer
16:53:56 <rkukura> ZangMingJie: I think both, maybe with plan to deprecate provider extension in J?
16:55:02 <mestery> rkukura: That's not a bad plan.
16:55:40 <rkukura> Main question is whether we really have consensus on moving away from existing provider extension/model to multi-provider with arbitrary attributes
16:56:09 <mestery> rkukura: I'll make a note to mention this during the Neutron team meeting next Monday, sound good?
16:56:19 <rkukura> I'd like to get markmcclain and other neutron cores to buy in on this
16:56:37 <Sukhdev_> Can you give a high level summary of this?
16:57:26 <rkukura> The provider extension uses fixes set of attributes (network_type, segmentation_id, phyiscal_network)
16:58:03 <mestery> rkukura: Added an item for the Neutron team meeting on Monday here: https://wiki.openstack.org/wiki/Network/Meetings#ML2_.28mestery.2Frkukura.29
16:58:10 <rkukura> With multiprovider extension and this patch, TypeDrivers define arbitrary attributes (only network_type is required)
16:58:37 <Sukhdev_> rkukur: thanks
16:58:44 <mestery> OK, lets continue this discussion on the ML and review, we're running short on time.
16:58:51 <mestery> #topic Open Discussion
16:58:55 <roaet> I was attempting to do https://bugs.launchpad.net/neutron/+bug/1196170 and was delayed many time (release, lots of things), and I was wondering if I should continue to rebase over and over again or is it no longer a valid task? If it is a valid task can I get direction/support so that it can be merged (I know it's wishlist, but just wanting to find a conclusion).
16:58:58 <mestery> Wanted to leave a few minutes for open discussion.
16:59:10 <roaet> (that wasn't prepared, I swear)
16:59:35 <sc68cal> just posted up my patches for the qos ml2 - I missed the change that removed mox - so it's still WIP
16:59:37 <mestery> roaet: I still think is a valid patch to work on.
16:59:58 <asadoughi> i was going to mention progress on ovs-firewall-driver blueprint, basic flows are working on the agent, but not there 100% as i learn more on using openvswitch
17:00:06 <mestery> roaet: Please post a new version and rkukura and I will review it in more detail again.
17:00:15 <mestery> sc68cal: Cool, will check those out!
17:00:20 <roaet> mestery: thank you. I will ping you both in os-neutron
17:00:40 <rkukura> roaet: ok
17:00:41 <mestery> asadoughi: Awesome!
17:01:20 <rkukura> asadoughi: Is there a followup meeting scheduled on that?
17:01:31 <mestery> OK, we're out of time now.
17:01:37 <ZangMingJie> ovs-firewall-driver is also on our schedule
17:01:38 <mestery> Lets continue discussions on ML and IRC.
17:01:41 <mestery> Thanks everyone!
17:01:42 <roaet> thanks
17:01:43 <mestery> #endmeeting