17:01:48 <colindixon> #startmeeting tws
17:01:48 <odl_meetbot> Meeting started Mon May 16 17:01:48 2016 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:01:48 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:48 <odl_meetbot> The meeting name has been set to 'tws'
17:01:48 <colindixon> #topic agenda bashing
17:02:10 <colindixon> #info today we'll cover the OpenFlow projects organization and future
17:02:29 <colindixon> #link https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=46200#Upcoming_Meeting_Agendas agenda
17:02:54 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/2016-May/thread.html#6475 thread on this topic
17:03:07 <colindixon> #link https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit the presentation Abhijit will be using
17:06:21 <colindixon> #topic openflow strategic items (organization of projects and future)
17:06:51 <colindixon> #info two key items: (a) reroganizing different openflow projects and (b) OpenFlow 1.5 support
17:07:10 <colindixon> #Info apparently, we're focusing on (a) today, but less so (if at all) on OpenFlow 1.5
17:07:40 <colindixon> #info we have lots of OpenFlow projects
17:08:14 <colindixon> #info tightly entwined: OpenFlow Protocol Library (openflowjava), openflowplugin, circuit switching extensions, and EPC extensions
17:08:23 <colindixon> #info less entwined: TTPs and OF-CONFIG
17:09:00 <colindixon> #info current issues:
17:09:04 <colindixon> #info 1.) some performance cost for double translation of models (once for openflowplugin and again for openflowjava)
17:09:25 <colindixon> #info 2.) patches often need to go into both the openflowplugin and openflowjava project
17:10:00 <colindixon> #info 3.) fewer resources available these days for OpenFLow-related projects
17:10:28 <colindixon> #info 4.) confusing to people who are looking for the "openflow support" in OpenDaylight
17:14:11 <colindixon> #info abhijitkumbhare mentions the cost of having two different models at two different levels: plugin and protoco library
17:14:30 <colindixon> #info colindixon asks if the performacne impact has been quantified, abhijitkumbhare says no, not right now
17:18:23 <colindixon> #info abhijitkumbhare talks about extension style projects, abhijitkumbhare says that ODL forge would be one place to house all the extension projects
17:18:49 <colindixon> #info vishnoianil asks about maybe using the top-level project and project managmenent committee
17:20:21 <colindixon> #info colindixon points out that the integration projects currently do this, but without needing to be top-level or have a PMC
17:20:44 <colindixon> #Info colindixon notes that ODL forge doesn't exit right now
17:24:06 <colindixon> #info rovarga says the biggest issue is really how these extensions are maintained and released, e.g., if it's never released, there's no risk that we have to support it
17:24:35 <colindixon> #info if we release it and do so as part of openflowpluging, then we have to maintain it
17:25:06 <colindixon> #info vishnoianil says he thinks we should take vendor extensions, only if there's a strong committment to support it
17:34:45 <colindixon> #info colindixon says that there are 3 main things we're talking about (1) code organization into repositories, (2) code organization in terms of the number of layers of abstraction and it's implication for performance, (3) how we get people to maintain the code (especially extensions) and if and how they get shipped as part of a release
17:35:04 <colindixon> #info colindixon asks what people think about aggregating all openflow projets under an openflow/ name (like integration)
17:35:50 <colindixon> #info rovarga says he likes it, but for now, as long as it's kept to the plugin, library, and extenions for now and maybe expanding later based on our experiences
17:36:14 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/2016-May/006522.html tykeal's comments on moving projects
17:36:45 <colindixon> #info vishnoianil says in his mind l2switch could even join, rovarga says he worries that most projects are very openflow specific and so everything might end up under openflow/
17:38:30 <colindixon> #info abhijitkumbhare agrees with rovarga to start small
17:38:54 <colindixon> #info colindixon points out that tykeal says above that moving projects would have to change their group IDs for artifacts
17:41:53 <colindixon> #info rovarga says that as long as somebody goes through and checks all the dependent projects and pushes the patches, it should be pretty easy, the old artifacts will be around for a while and it won't break anyone
17:43:05 <colindixon> #info colindixon asks under what circumstances (if any) would we allow extensions into the openflow plugin project itself?
17:44:16 <colindixon> #info abhijitkumbhare says that some crtieria might be vendor neutrality and system tests
17:45:51 <colindixon> #info colindixon asks if we ship OF extensions that are part Boron and then the project that was providing them (which isn't openflowplugin) drops out of Carbon, do we think users will correctly blame that project and not openflowplugin
17:47:26 <colindixon> #info colindixon's point is really that if we worry about being held accountable for teams vanishing, merely keeping the functionality out of openflowplugin itself might not help as much as we'd like
17:49:35 <colindixon> #info it seels like we agreement on moving openflow{plugin,java} and extensions under one group
17:49:38 <colindixon> #info otherwise, we don't
17:49:43 <colindixon> #undo
17:49:43 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x28bd350>
17:50:33 <colindixon> #info vishnoianil asks if we should even ship vendor extensiosn with the simultanteous release, e.g., just point to the external jars/bundles/feature-repos intead of shipping with it
17:52:38 <colindixon> #info rovarga notes that right now, projects can provide extensions and be part of the release if they want to, we'd need to change our rules to not allow them to participate
17:56:18 <colindixon> #info colindixon and abhijitkumbhare say that good examples on both sides of this are things like the Nicira extensions, which we probably do want in OpenDayligth by default, but there are other extensions which are clearly more niche and might be find to not ship
17:57:17 <colindixon> #info rovarga suggests maybe having things need to be standardized or implemented by two or more vendors first, might help wiht that problem
17:58:30 <colindixon> #info colindixon worries that it might be hard to make it clear that this was objective, also it doesn't help that we also need to figure out how it will stay maintained
17:58:53 <colindixon> #endmeeting