16:04:12 <rkukura> #startmeeting networking_ml2
16:04:14 <openstack> Meeting started Wed Feb  4 16:04:12 2015 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:18 <openstack> The meeting name has been set to 'networking_ml2'
16:04:44 <yamamoto> hi
16:04:50 <trinaths1> hi
16:04:57 <rkukura> #link Agenda https://wiki.openstack.org/wiki/Meetings/ML2
16:05:26 <rkukura> #topic Announcements
16:06:01 <rkukura> My only annoucement is that mestery plans to cut kilo-2 today if possible
16:06:24 <mestery> rkukura: Ack, by tomorrow morning for sure. Just waiting on one final BP which has a single patch left, and a handful of bugs.
16:06:40 <rkukura> See https://wiki.openstack.org/wiki/Meetings/ML2 for what’s left
16:07:23 <rkukura> Looks to me like the only items for ML2 that hasn’t yet merged but might is https://bugs.launchpad.net/bugs/1179223
16:07:59 <rkukura> Is Romil here?
16:09:00 <rkukura> This is the bug about tunnel allocations not getting cleaned up. Would be great to get reviews today from those most familiar with the type driver code.
16:09:28 <rkukura> Any other announcements?
16:10:11 <rkukura> #topic ML2 Drivers decomposition discussion
16:11:21 <rkukura> So its seems we are making progress on this, and there was discussion at the neutron IRC meeting Monday. What do we need to cover today?
16:11:34 <shivharis> Sukhdev: how did u maintain the history of comments for your driver (splited)
16:12:13 <Sukhdev> shivharis: what do you mean?
16:12:33 <Sukhdev> when you pull the stackforge repo - there are two ways to do it
16:12:59 <Sukhdev> 1) you can pull the code directly from the neutron tree - that will keep all the history
16:13:23 <trinaths1> Sukhdev: can we have a doc on code split like you have helping doc for CI.
16:13:29 <Sukhdev> 2) you do not pull anything and get a clean repo - this will not keep any history and logs
16:13:49 <shivharis> how will your historical comments show up in the stackforge repo?
16:14:19 <Sukhdev> trinaths1: I might, if more people want it - but, you can look at my patches - it is all done and it is going in K2 today
16:14:23 <shivharis> if i do git log in stackforge will it show the comments logs from earlier releases?
16:14:31 <trinaths1> shivharis: (doubt for new bee) "Historical Comments"?
16:15:03 <shivharis> when you make changes to your code - you maintain a history and the abitlity to go backwards
16:15:07 <Sukhdev> shivharis: if you created stackforge with 1) above, then, yes - otherwise no
16:15:40 <trinaths1> shivharis: okay
16:15:57 <Sukhdev> shivharis: actually, I think before you take my word for it, please double check with infra folks
16:16:14 <trinaths1> Sukhdev: how to init into stackforge with a project. - may be you can help me offline.
16:16:24 <shivharis> here is what i did:
16:16:41 <Sukhdev> trinaths1: please ping me off-line and I will help
16:16:49 <trinaths1> Sukhdev: thanks you
16:17:03 <shivharis> you need to use "split.sh" to do the split and give it a list of files that you want to maintain the histroy and deltas for, including "tags"
16:17:30 <shivharis> so you will be able to go back to stable releases if you want to
16:18:28 <shivharis> appears folks have not tried this approach?
16:18:55 <shivharis> never mind lets move on...
16:18:58 <Sukhdev> shivharis: does it work if you are moving parts of the files?
16:19:21 <shivharis> granularity is a file
16:19:34 <manishg> Sukhdev, if you can move the file and then in next rev edit and remove the parts you don't need.  That way you have the history.
16:19:38 <shivharis> the entire history of the file is maintained
16:20:10 <Sukhdev> good to know…
16:20:31 <rkukura> OK, seems useful to include the history, but not critical since we are not decomposing for releases prior to kilo, right?
16:20:54 <Sukhdev> rkukura: correct -
16:21:09 <shivharis> rkukura: it depends on the plugin/driver, some plugins have long histories
16:21:24 <manishg> rkukura: sometimes people wipe out content thinking they can go back.  Only to realize a year later things moved around and that code is lost.
16:22:03 <rkukura> The history will remain in the neutron repo, so I don’t see risk of losing anything.
16:22:04 <shivharis> I think the problem will arise when you use a tag for neutron and a similar tag in not available in the driver
16:22:51 <manishg> rkukura: that's true.
16:22:57 <rkukura> Any other issues related to decomposition that anyone would like to discuss today?
16:23:02 <trinaths1> Sukhdev: what is the deadline for this code split?
16:23:17 <Sukhdev> trinaths1: You have until next release cycle
16:23:17 <shivharis> rkukura: maybe alright, but we need to specify a method the we commonly use?
16:23:25 <trinaths1> Sukhdev: L ?
16:23:34 <Sukhdev> trinaths1: yes
16:23:37 <shivharis> k3?
16:23:44 <trinaths1> shivharis: L-3
16:23:44 <shivharis> or L
16:23:48 <shivharis> ok
16:23:59 <trinaths1> Sukhdev: Am I correct L-3 ?
16:24:11 <Sukhdev> trinaths1: yes
16:24:16 <rkukura> Do we know of drivers for which decomposition is planned for L rather than K?
16:24:39 <Sukhdev> rkukura: Hard to tell
16:24:44 <shivharis> I am shooting for k3
16:24:57 <shivharis> brocade is shooting for k3
16:25:23 <Sukhdev> as long as some work is initiated in Kilo, it is OK to complete in L
16:25:24 <shivharis> I have one more question:
16:25:24 <rkukura> I only see kilo mentioned in https://docs.google.com/spreadsheets/d/1OQN0VlKzKC1gYlxgalQXKDTGGWogWFRtD3S5OpepsX4/edit#gid=0
16:25:25 <trinaths1> Freescale for L-1
16:25:41 <rkukura> trinaths1: OK, thanks
16:25:50 <rkukura> shivharis: go ahead
16:25:53 <Sukhdev> shivharis: keep in mind, you need two CIs working - before you declare victory
16:26:05 <trinaths1> Sukhdev: two CI's ?
16:26:17 <shivharis> When you pull neutron, what are the steps needed to pull your stackforge, I just want to find out what others are doing
16:26:31 <Sukhdev> trinaths1: Yes - one for the neutron repo and another for stackforge repo
16:27:10 <trinaths1> Sukhdev: but for stackforge, I see Jenkins like jobs apart from them We  need Vendor CI ?
16:27:20 <rkukura> Sukhdev: Is the one for the neutron repo the one that runs the tempest tests using the decomposed driver and pulling in the stackforge repo?
16:27:21 <shivharis> is stackforge repo CI optional?
16:27:32 <trinaths1> shivharis: +1
16:27:40 <Sukhdev> rkukura: yes
16:27:58 <Sukhdev> shivharis: no - how are you going to know if things are broken -
16:28:02 <rkukura> Sukhdev: And is the other the vendor’s own CI for the stackforge repo standalone?
16:28:08 <Sukhdev> shivharis: in fact, that is the most useful one
16:28:52 <trinaths1> Sukhdev: confused? why we need a vendor CI for Stackforge? What tests does it run apart from Neutron -Vendor CI?
16:29:00 <rkukura> Sukhdev: I would think some vendors might consider unit tests in their stackforge repos sufficient, and depend on the neutron-based CI for integation testing.
16:29:16 <Sukhdev> rkukura: the stackforge CI to ensure the authencity of the vendor code
16:29:36 <GLaupre> I am confused, CI means?
16:29:52 <trinaths1> GLaupre: Continuous Integration Testing
16:30:23 <shivharis> You cannot run the vendor CI, since it imports "neutron" and "openstack" modules
16:30:25 <Sukhdev> There seems to be a confusion about CIs
16:30:42 <ChuckC_> is there documentation somewhere that can help with this confusion?
16:30:52 <shivharis> Sukhdev: I dont see how you can even run a standalone CI?^^^^^
16:31:19 <rkukura> I’m not aware of any explciit requirement for “autromated standalone CI” of the stackforge repos. Vendors may be OK with just running the UTs as CI, or may want to test against their hardware.
16:31:37 <trinaths1> TWO CIs are causing confusion on their importance and tests they run
16:32:33 <Sukhdev> If you are OK with the UT on the stackforge side, you may want to skip the CI - but, how are going to test the breakage between Neutron-and-vendor interaction?
16:32:56 <shivharis> standalone CI has to be optional, in some enviroments it may not even be possible
16:33:30 <Sukhdev> If you make a change to vendor code which breaks neutron-driver interaction - how do you intend to catch it? If your UTs are smart enough, you may not need it
16:33:59 <rkukura> My view is that only the neutron-based CI is required by the neutron community. How to develop and test the backend library is the vendor’s business.
16:34:12 <shivharis> rkukura: +1
16:34:33 <trinaths1> rkukura: +2
16:34:50 <banix> Sorry got disconnected. Will check the logs later.
16:34:55 <rkukura> Sukhdev: Does that make sense to you, or do you feel there is a reuiqment here?
16:35:16 <rkukura> requirement
16:35:31 <rkukura> banix: still on decomposition
16:35:40 <Sukhdev> rkukura: I think you are probably correct - I have not read any requirement as such
16:36:08 <rkukura> Anything else on decomposition before we move on to sync and error handling?
16:36:14 <Sukhdev> rkukura: I believe as long as vendors ensure the integrity of their code, it is their own busniess
16:36:32 <rkukura> Sukhdev: agreed
16:36:33 <shivharis> I had an earlier questions... tracing back..
16:36:37 <Sukhdev> rkukura: just a quick note
16:36:45 <trinaths1> Sukhdev: that way, stackforge Vendor CIs are not of priority
16:37:07 <shivharis> Q: When you pull neutron, what are the steps needed to pull your stackforge, I just want to find out what others are doing
16:37:58 <Sukhdev> If you have a CI already running modifying it to do the tests for stackforge is very trivial - you simply look for additional triggers
16:38:21 <Sukhdev> shivharis: there are multiple ways to do it
16:38:31 <shivharis> listening...
16:38:56 <Sukhdev> Once you have finalized everything - it will be very trivial like "pip install networking_brocade"
16:39:08 <banix> Sorry this is what I wrote earlier but got lost: note some drivers may be not in StackForge so only one CI is required.
16:39:18 <Sukhdev> prior to finalizing everything - here is the quick way to test it
16:39:38 <Sukhdev> 1) git clone <stack-forge repo>
16:39:43 <Sukhdev> 2) cd to it
16:39:54 <Sukhdev> 3) python setup.py install
16:40:02 <Sukhdev> and you are done
16:40:07 <shivharis> pip install installs in the /usr/local I am talking about development environment
16:40:11 <Sukhdev> to test it - do the following
16:40:13 <manishg> rkukura: should we document this somewhere?  maybe Sukhdev or someone can volunteer to set something up and we could move on?
16:40:16 <Sukhdev> 1) python
16:40:25 <trinaths1> manishg: +1
16:40:36 <Sukhdev> 2) >>>>import networking_brocade and you should see all the code
16:40:55 <rkukura> Should this go in the devref that armax has been working on?
16:41:30 <Sukhdev> rkukura:what devref?
16:41:38 <shivharis> Sukhdev: thanks, but how does one iterate this in the dev env
16:41:50 <manishg> I'll be back in a couple of minutes.
16:42:08 <rkukura> http://docs.openstack.org/developer/neutron/devref/
16:42:12 <Sukhdev> shivharis: easy - in my CI, I have couple of lines before I fire off stack.sh
16:42:54 <Sukhdev> rkukura: tahnks
16:43:07 <shivharis> my question is prior to CI, I want to commit a change to stackforge, where was this stackforge deposited?
16:43:39 <Sukhdev> shivharis: you lost me
16:43:52 <shivharis> was this stackforge within the neutron tree?
16:43:55 <rkukura> manishg: I’d like to reserve a couple minutes at least for your update on sync/errors
16:44:18 <manishg> rkukura: no worries.  I'm here.
16:44:20 <banix_> rkukura: +1 need to talk rsync!
16:44:39 <manishg> rkukura: I also wanted to talk about the wiki and the format, etc. + how to proceed.
16:44:39 <Sukhdev> shivharis: still confused --- these are two separate repos, right?
16:44:56 <shivharis> rkukura: I have many questions, I dont want to occupy the entire meeting...
16:45:02 <Sukhdev> manishg: I took a look - it looked fine to me
16:45:17 <shivharis> rkukura: please move on..
16:45:33 <manishg> Sukhdev: cool.  will propose some items when we get to that task in the meeting.
16:45:36 <Sukhdev> shivharis: Ping me off line and I will help you out
16:45:48 <rkukura> shivharis: If you are willing to capture info in a wiki or google doc, I’d expect those who’ve done this before will be happy to advize you offline
16:46:09 <shivharis> i have done most of it, i am getting finer points clarified
16:46:28 <rkukura> OK, lets move on…
16:46:42 <Sukhdev> shivharis: perhaps we can collectively put together a wiki for ML2 drivers
16:46:42 <rkukura> #topic ML2 Sync and error handling (Task Flow)
16:46:48 <trinaths1> Sukhdev: has to take tutorials for me and manishg
16:47:12 <manishg> rkukura: I followed up re the API/ RPC breakup in kilo
16:47:20 <manishg> it's been pushed out to K-3.
16:47:24 <rkukura> I’d suggest capturing the knowledge in a wki or google doc, then we can see if it makes sense to add it to the devref later
16:47:28 <manishg> Relevant specs are these:
16:47:35 <manishg> https://blueprints.launchpad.net/neutron/+spec/wsgi-pecan-switch
16:47:41 <manishg> https://blueprints.launchpad.net/neutron/+spec/plugin-interface-perestroika
16:48:10 <manishg> I have resumed working on the patch re taskflow.  It is a WIP.  The main idea is
16:48:20 <Sukhdev> rkukura: you are referring to wiki/google doc for decomosition work, right?
16:48:33 <banix_> manishg: please post the link o your wip patch
16:48:51 <rkukura> Sukhdev: right, but I didn’t want to undo the topic change ;)
16:49:16 <manishg> to basically start a taskflow threadpool executor and dispatch tasks to it from the mech drivers.  This was the simple start. And I'm going to start it based on some work done recently https://review.openstack.org/#/c/136950/
16:49:19 <Sukhdev> rkukura: got it
16:49:43 <manishg> This was done by Angus based on my earlier WIP.  I'll take this and add more to it.  The next steps in this ar
16:49:50 <manishg> are to introduce intermediate states.
16:50:11 <manishg> once that is done, the REST call can return without the mech drivers finishing up.
16:50:14 <rkukura> manishg: How about adding this to the Planned section of https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews with relevant links
16:50:30 <manishg> rkukura: good idea.  will add that today.
16:50:57 <Sukhdev> manishg: I think your thought process is correct
16:50:58 <rkukura> manishg: Does this approach provide any persistance for these tasks, in case the server dies before they complete?
16:51:11 <manishg> who all are interested in this ?  Sukhdev , shivharis and rkukura - I'll post a new patch today and email to you guyus.
16:51:44 <Sukhdev> manishg: yes, please do - may include banix_ as well
16:51:47 <shivharis> manishg: does the task take arguments for the callback?
16:51:48 <manishg> rkukura: yes that can be done.  but in the patch I want to go incrementally so people can see small changes (conceptually) at a time.
16:52:00 <rkukura> manishg: OK. Doesn’t hurt to CC openstack-dev if you want.
16:52:09 <banix_> yes please
16:52:15 <manishg> rkukura: ok, will do.
16:52:35 <shivharis> i am very interested in this
16:53:00 <manishg> shivharis: yes, we can make it as complex or simple as needed.  the capability can be added and the driver has the freedom to store any kind of state that it may need.
16:53:00 <rkukura> OK, we have 8 minutes. Lets continue this discussion next week after we’ve looked over the current code.
16:53:17 <manishg> rkukura: sure.  I'll add on to this by next week.
16:53:18 <Sukhdev> shivharis is willing pay extra royalty for this :-):-)
16:53:26 <rkukura> #topic Bugs
16:53:27 <shivharis> manishg: thanks
16:53:38 <rkukura> shivharis: want to cover this?
16:53:40 <shivharis> bugs...
16:54:00 <GLaupre> :)
16:54:06 <shivharis> We have one high bug being handled by romilg
16:54:13 <manishg> rkukura: wanted to just mention that re wiki people should add anything that should be reviewed in there.  and remove it when done.
16:54:35 <shivharis> rest of the high bugs (being addressed by neutron cores) are now k3
16:54:37 <rkukura> manishg: sorry, didn’t mean to skip that topic
16:54:46 <shivharis> so we dont have any pressing bug for k2
16:54:50 <rkukura> but lets finish bugs first
16:55:18 <shivharis> we look fine for bugs at the moment.
16:55:20 <manishg> rkukura: sure.
16:55:51 <shivharis> i am really done with bugs, no pressing need for k2 except the bug addressed buy romilg
16:56:04 <shivharis> please provide review help ASAP for that
16:56:12 <rkukura> I’ll review https://review.openstack.org/136106, others should too
16:56:31 <rkukura> #topic BPs
16:56:44 <Sukhdev> FYI - here is the content for K2 - https://launchpad.net/neutron/+milestone/kilo-2
16:56:46 <manishg> wanted to say that we shouldn't expect someone to constantly scan gerit and update it for them.
16:57:03 <manishg> that makes sense?
16:57:10 <rkukura> Thanks manishg for pairing down https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews to the active BPs
16:57:23 <manishg> also, if the format needs to be changed, we can discuss it now.
16:57:43 <manishg> e.g. we need to add more fields, etc.  Looks like the current one is good enough for reviews and general tracking.
16:58:05 <rkukura> yamahata and shwetaap have been working on portsecurity - update?
16:58:18 <shwetaap> For the port security bp, as per the suggestion yesterday i have two different patches. One for the modification on the extension api  https://review.openstack.org/#/c/152759/ and the other for the specific port security driver.
16:58:28 <shwetaap> https://review.openstack.org/#/c/150835/
16:58:43 <manishg> shwetaap - I added link to them both in the link
16:58:59 <shwetaap> manishg: thanks
16:59:00 <manishg> please verify them.  also, when the code is merged, please clear it from here.
16:59:08 <rkukura> Lets review the extension driver API changes ASAP so they can move forward
16:59:25 <manishg> rkukra: that's not in the list here?  should be added?
16:59:38 <rkukura> I believe the two remaining HPB patches are ready to merge
17:00:00 <rkukura> thanks to help from matrohon on tracking down the DVR CI issue they were hitting
17:00:13 <manishg> ok.  If BP needs review or has code that relevant to BP then pls add here.
17:00:16 <shivharis> time check -1 mins left :-)
17:00:18 * Sukhdev time check
17:00:21 <rkukura> Time’s up - anything before we conclude?
17:00:28 <shwetaap> ok i will add the link
17:00:40 <rkukura> Thanks everyone!
17:00:42 <manishg> thanks rkukura!
17:00:42 <banix_> bye all
17:00:44 <Sukhdev> thnaks
17:00:44 <manishg> bye.
17:00:44 <rkukura> #endmeeting