18:00:53 <colindixon> #startmeeting tsc
18:00:53 <odl_meetbot> Meeting started Thu Jan 21 18:00:53 2016 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:00:53 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:53 <odl_meetbot> The meeting name has been set to 'tsc'
18:00:57 <dfarrell07> #info Daniel Farrell
18:00:58 <colindixon> #topic agenda bashing and roll call
18:01:26 <colindixon> #info colindixon
18:01:30 <abhijitkumbhare> hi folks
18:01:35 <LuisGomez> #info LuisGomez
18:01:56 <colindixon> #link https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=40433#Agenda the agenda in it's usual place
18:02:24 <ChrisPriceAB> #info Chris price
18:03:22 <colindixon> #action phrobb, gzhao, jmedved, ChrisPriceAB, and others to continue to figure out when/where/who would run a Europe boot camp
18:03:46 <colindixon> #undo
18:03:46 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x2243710>
18:03:55 <colindixon> #action colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade to Boron?
18:04:04 <colindixon> #action colindixon to keep boron planning on our minds
18:04:06 <dfarrell07> #info ChrisPriceAB et al have made progress on Europe boot camp, will cycle back when there are updates
18:04:28 <mohnish_> #info mohnish anumala
18:04:34 <snackewm> #info eric multanen
18:04:44 <edwarnicke> #info edwarnicke
18:04:58 <colindixon> #topic events
18:05:09 <colindixon> #link https://www.opendaylight.org/global-events
18:05:18 <edwarnicke> #info phrobb- is missed
18:05:52 <colindixon> #link https://www.opendaylight.org/events/2016-02-29-000000-2016-03-01-000000/opendaylight-developer-design-forum pleas register to attend an book travel for the developer designg forum on 2/29 and 3/1
18:06:06 <dfarrell07> w00t cookies ;)
18:06:32 <jamoluhrsen> Int/test looking forward to the cookies!
18:06:36 <colindixon> #info CFP for the OpenStack summit closes 2/1
18:07:36 <dfarrell07> did anyone else loose audio?
18:07:46 <colindixon> dfarrell07: nope
18:07:52 * dfarrell07 hangs up and tries again
18:08:05 <colindixon> #topic boron
18:08:18 <colindixon> #chair anipbu
18:08:18 <odl_meetbot> Current chairs: anipbu colindixon
18:08:35 * dfarrell07 has audio again
18:08:51 <colindixon> #info branch cutting and version bumping was complete last week, but yang tools has asked to bump to 1.0.0 instead of 0.9.0
18:09:33 <colindixon> #info zxiiro says he plans to do that bump today, he asks about date-based-versions, tony says it shoudl be gone now, so should be fine
18:09:50 <colindixon> #info tony says they're all now in MD-SAL
18:10:28 <colindixon> #info for what it's worth we now have master branches that will become Boron, we will remove the now unused pre-boron branches in 3 weeks
18:10:52 <colindixon> #action zxiiro to start a thread on whether pre-boron and what we shoudl do in the future
18:12:07 <colindixon> #info rovarga_ says there are bunch fo projects to disable JDK7 verification for boron, he'd like them to do that
18:12:14 <ChrisPriceAB> Ack
18:12:35 <colindixon> #startvote shall the TSC agree that we will not support JDK7 in Boron, it will focus on JDK8? -1, 0, +1
18:12:35 <odl_meetbot> Begin voting on: shall the TSC agree that we will not support JDK7 in Boron, it will focus on JDK8? Valid vote options are -1, 0, +1.
18:12:35 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
18:12:42 <dfarrell07> #vote +1
18:12:44 <ChrisPriceAB> #vote +1
18:12:46 <colindixon> #vote +1
18:12:50 <edwarnicke> #vote +1
18:12:51 <LuisGomez> #vote +1
18:13:05 <mohnish_> #vote +1
18:13:14 <snackewm> #vote +1
18:13:15 <dfarrell07> snackewm:
18:13:19 <colindixon> #endvote
18:13:19 <odl_meetbot> Voted on "shall the TSC agree that we will not support JDK7 in Boron, it will focus on JDK8?" Results are
18:13:19 <odl_meetbot> +1 (7): ChrisPriceAB, LuisGomez, edwarnicke, dfarrell07, colindixon, mohnish_, snackewm
18:13:31 <colindixon> #agree Boron will not support Java 7, it will target Java 8
18:13:58 <colindixon> #topic beryllium
18:14:57 <colindixon> #info merge jobs currently build with Java 7, while autorelease builds with Java 8, which means SNAPSHOTS are built from Java 7 while release artifacts are built with Java 8
18:15:26 <colindixon> #info rovarga_ says for arcane reasons with maven embedding the build environment, we should actually build in autorelease with Java 7 instead of Java 8
18:16:10 <colindixon> #action zxiiro to move autorelease to building with Java 7
18:16:54 <colindixon> #Info build for RC0 will start at midnight UTC today, after that projects will be asked download and test later today or tomorrow
18:17:05 <anipbu> #link https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-beryllium/22/
18:17:28 <colindixon> #Info we ask projects to test the autorelease beryllium build (above) for unstable tests
18:17:49 <anipbu> #link https://wiki.opendaylight.org/view/Weather#BUG-4295:_Lazy_Data_Tree_MERGE_operations
18:18:05 <colindixon> #info bug 4295 (above) was merged as a weather event, with no fallout observed yet other than one bug in NETCONF test
18:18:23 <colindixon> #topic system integration and test
18:18:43 <colindixon> #info due to infrastructure issues, many CSIT tests weren't working, it seems to have been fixed last night and things seem pretty stable
18:19:07 <colindixon> #info there are still projects with no system tests at M5, there are other that have tests that do nothing
18:19:13 <colindixon> #info jamoluhrsen will follow up with people that don't have them
18:19:56 <colindixon> #action jamoluhrsen and anipbu to make sure we have system test status, i.e., do they exist, tracked on the main spreadsheet so we can cover it next week
18:20:16 <colindixon> #info colindixon begs to reuse the main tracking sheet vs. creating a new
18:21:10 <colindixon> #topic infrastructure
18:22:07 <colindixon> #info we've had issues all week causing all CSIT stuff to fail, there was a bug in neutron that caused VMs that came up in error states to not release their ports, and we ran out of ports pretty quickly
18:22:35 <colindixon> #info we still have that issue, but rackspace has a script to clean up the ports they can run when needed
18:23:04 <colindixon> #info colindixon asks how long we'll be OK, zxiiro says he doesn't know
18:24:06 <colindixon> #info this was affecting everything, but CSIT jobs were more likely to fail because they created more slaves
18:24:25 <colindixon> #topic Stephen Kitt as a committer odlparent
18:24:36 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004559.html the ask for the vote
18:25:01 <colindixon> #info links to his work are in that e-mail
18:25:40 <dfarrell07> #info skitt also has patches to 30+ ODL projects
18:25:53 <colindixon> #info zxiiro and edwarnicke argue the case is pretty clear, ~50 patches merged and open to odlparent
18:25:57 <edwarnicke> dfarrell07: :)
18:26:29 <colindixon> #startvote shall the TSC approve Stephen Kitt as a committer on the odlparent project? -1, 0, +1
18:26:29 <odl_meetbot> Begin voting on: shall the TSC approve Stephen Kitt as a committer on the odlparent project? Valid vote options are -1, 0, +1.
18:26:29 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
18:26:31 <ChrisPriceAB> #vote +1
18:26:31 <edwarnicke> #vote +1
18:26:33 <dfarrell07> #vote +1
18:26:33 <colindixon> #vote +1
18:26:34 <LuisGomez> #vote +1
18:26:34 <mohnish_> #vote +1
18:26:35 <snackewm> #vote +1
18:26:39 <colindixon> #endvote
18:26:39 <odl_meetbot> Voted on "shall the TSC approve Stephen Kitt as a committer on the odlparent project?" Results are
18:26:39 <odl_meetbot> +1 (7): LuisGomez, dfarrell07, ChrisPriceAB, edwarnicke, colindixon, mohnish_, snackewm
18:26:47 <colindixon> #agreed Stephen Kitt is now a comitter on odlparent
18:26:50 * edwarnicke only wishes he could give more + ;)
18:26:55 <dneary> Congratulations skitt!
18:27:09 <colindixon> #topic openflow plugin design conflict
18:27:35 <colindixon> #link https://lists.opendaylight.org/pipermail/release/2016-January/005241.html colin's summary
18:28:24 <colindixon> https://lists.opendaylight.org/pipermail/tsc/2016-January/004562.html
18:29:56 <colindixon> #undo
18:29:56 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x223b610>
18:30:16 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2016-January/004562.html colin's summary of the situation
18:30:56 <colindixon> #info we have two designes of the openflow plugin, unfortuntely we have 2 proejcts that cant use the new one (VTN and VPNService) and 2 projects that can't use the od one (DIDM and NIC)
18:31:44 <colindixon> #Info hideyuki notes that the performance of the new one is poor (500ms to install a single flow) and there are some RPCs missing in the new one that they use, hideyuki says they'd need 2 weeks to migrate even if the performance issues went away
18:32:13 <rovarga_> hideyuki: the RPC latency is for a single invocation, right?
18:32:35 <hideyuki> The above two problems are what we observed during our *quick tests*. So if we do more tests, we would find more problems.
18:33:20 <hideyuki> rovarga_: It takes 500 msec to install a flow entry when VTN Manger calls a add-flow RPC.
18:33:34 <colindixon> #info vishnoianil says as he understands it, the only blocking feature from the projects using the new plugin is sending table features messages and that could be added to the old plugin, then DIDM and NIC should be able to use the old plugin
18:34:21 <abhijitkumbhare> thanks vishnoianil - if you are able to handle the change
18:34:48 <colindixon> #action vishnoianil anipbu abhijitkumbhare to figure out if this will actually enable DIDM and NIC to fall back and then coording the effort
18:34:57 <rovarga_> hideyuki: right, that is caused because the RPC only returns when we know that flow got installed -- which requires the use of barrier. The plugin issues barriers automatically every 500msec or every 1000 flows. You can also pass down an explicit barrier (which will reset internal counters)
18:35:00 * dfarrell07 is super stoked that vishnoianil seems to have a less-painful option!
18:35:11 <rovarga_> hideyuki: once the barrier response comes back, all preceding RPCs are completed
18:35:32 <colindixon> #action anipbu to talk to the remaining 7 projects that haven't voted, but I *think* they're all using the old plugin, so this would work for them
18:35:44 <colindixon> #info anipbu notes that some support both, e.g., OVSDB
18:36:38 <colindixon> #info rovarga_ says that any project using FRM should get this for free, anyone using RPCs will have an easy migration, if you snoop on things like port_up and port_down that will be harder to migrate
18:37:25 <colindixon> #info dfarrell07 says one reason people moved to the new design was to suppport clustering, but there have been efforts to make clustering also work in the old design
18:37:43 <colindixon> #info LuisGomez sasy that neither one is totally stable in a cluster now
18:38:14 <colindixon> #info rovarga_ also notes that the openflowplugin project doesn't have the bandwidth to support both designs in the long run
18:39:26 <rovarga_> #info I will note this is a reality now, even in short term I worry about sustainability here ..
18:39:39 <colindixon> #action colindixon to follow with this issue to figure out lessons learned and how to avoid this in the future
18:43:22 <colindixon> #info anipbu says that the end-goal as he understands it is to move to the lithium (new) deisgn
18:44:15 <colindixon> #info mohnish_ asks if we should strive to move foward not backward, e.g., get people to move to the new design instead of asking people to move backward
18:47:33 <icbts> Notes: We fix Feature uninstall up in Karaf 4 significantly over Karaf 3
18:47:47 <colindixon> #info edwarnicke notes that this hits an annoying spot where both OpenFlow plugins need access to the relevant ports and that causes failures, so we need to agree on this, but our culture tends to let people disagre, hence this dilemma
18:48:00 <rovarga_> icbts: yup, unfortunately we cannot move to it
18:48:08 <icbts> rovarga_: :(
18:48:41 <rovarga_> icbts: and even then, since we have persistent state, dealing with the osgi dynamics makes us do very hard decisions
18:48:57 <colindixon> #Info rovarga_ asks if there are sane ways that you would load apps that use different plugins, ChrisPriceAB gives an example that he wants in OPNFV which might trigger things
18:49:28 <rovarga_> icbts: essentially we need lifecycle hooks to know when the container has stabilized and is at a place when the user is happy to say 'go!'
18:51:32 <colindixon> #info in essense, I think rovarga_ says that we could maybe just provide a list of features and which plugin they use and that would then result in this being a non-issue because you won't ever load features that end up using both plugins
18:51:35 <edwarnicke> #info rovarga_ notes that it is likely that features using different versions of the OFplugin are already in conflict independent of the question of which OFplugin is used
18:51:38 <icbts> rovarga_: make a feature enhancement request to Karaf for a “User Space is stable” service. ie. If wirings / life cycle changes are in progress, report “False” - if container is stable and no registered services are waiting/cycling, than report “True” ?
18:52:30 <rovarga_> icbts: I need to think about it a bit more, but yes, I will raise a request
18:53:01 <hideyuki> rovarga_: Thank you for your information. Yes, we are aware that "how to send BARRIER_REQUEST" is different between the OFP-Li and the OFP-He. And, we know that we can explictly sned BARRIER_REQUEST by executing "send-barrier" RPC. We need code changes for that difference, too.
18:53:34 <colindixon> #action anipbu rovarga_ colindixon and others to reach out to figure out if it will suffice to have a list of features that use OpenFlow plugin and docuemnt which plugin to load for each feature to make sure that there are new conflicts, in which case we could move forward
18:54:38 <hideyuki> rovarga_: But, in a basic scenario, it takes about 48 secs to complete all flow entires (i'm not sure but maybe about 20 entires?) with the OFP-Li.  We are not sure yet if that slow is caused only by the BARRIER_REQUEST thing.
18:56:16 <colindixon> #info note there are background conversations between hideyuki and rovarga_ about VTNs use fo openflow plugin
18:57:36 <colindixon> #info note there are background conversations between icbts and rovarga_ about Karaf issues with features and moving to Karaf 4
19:02:29 <colindixon> #info as of now, we have established that only NIC and DIDM are really using (or testing) the new design, so this makes the two approaches somewhat saner than edwarnicke previously thought when he thought more people were were using an testing against the new design than that
19:03:55 <alagalah|alt> colindixon: This is the 2nd time GBP has been punted from Mature review. Realise there are important issues but perhaps we could be bumped up the batting order for next week's agenda ?
19:04:08 <colindixon> alagalah|alt: noted
19:04:21 <colindixon> alagalah|alt: assuming Beryllium isn't on fire, I agree
19:04:38 <alagalah|alt> colindixon: yes, clearly :)
19:04:42 <colindixon> #topic cookies
19:04:49 <colindixon> #endmeeting