#opendaylight-meeting: tws

Meeting started by colindixon at 17:01:48 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 17:01:48)
    1. today we'll cover the OpenFlow projects organization and future (colindixon, 17:02:10)
    2. https://wiki.opendaylight.org/index.php?title=Tech_Work_Stream:Main&oldid=46200#Upcoming_Meeting_Agendas agenda (colindixon, 17:02:29)
    3. https://lists.opendaylight.org/pipermail/discuss/2016-May/thread.html#6475 thread on this topic (colindixon, 17:02:54)
    4. https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit the presentation Abhijit will be using (colindixon, 17:03:07)

  2. openflow strategic items (organization of projects and future) (colindixon, 17:06:21)
    1. two key items: (a) reroganizing different openflow projects and (b) OpenFlow 1.5 support (colindixon, 17:06:51)
    2. apparently, we're focusing on (a) today, but less so (if at all) on OpenFlow 1.5 (colindixon, 17:07:10)
    3. we have lots of OpenFlow projects (colindixon, 17:07:40)
    4. tightly entwined: OpenFlow Protocol Library (openflowjava), openflowplugin, circuit switching extensions, and EPC extensions (colindixon, 17:08:14)
    5. less entwined: TTPs and OF-CONFIG (colindixon, 17:08:23)
    6. current issues: (colindixon, 17:09:00)
    7. 1.) some performance cost for double translation of models (once for openflowplugin and again for openflowjava) (colindixon, 17:09:04)
    8. 2.) patches often need to go into both the openflowplugin and openflowjava project (colindixon, 17:09:25)
    9. 3.) fewer resources available these days for OpenFLow-related projects (colindixon, 17:10:00)
    10. 4.) confusing to people who are looking for the "openflow support" in OpenDaylight (colindixon, 17:10:28)
    11. abhijitkumbhare mentions the cost of having two different models at two different levels: plugin and protoco library (colindixon, 17:14:11)
    12. colindixon asks if the performacne impact has been quantified, abhijitkumbhare says no, not right now (colindixon, 17:14:30)
    13. abhijitkumbhare talks about extension style projects, abhijitkumbhare says that ODL forge would be one place to house all the extension projects (colindixon, 17:18:23)
    14. vishnoianil asks about maybe using the top-level project and project managmenent committee (colindixon, 17:18:49)
    15. colindixon points out that the integration projects currently do this, but without needing to be top-level or have a PMC (colindixon, 17:20:21)
    16. colindixon notes that ODL forge doesn't exit right now (colindixon, 17:20:44)
    17. 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 (colindixon, 17:24:06)
    18. if we release it and do so as part of openflowpluging, then we have to maintain it (colindixon, 17:24:35)
    19. vishnoianil says he thinks we should take vendor extensions, only if there's a strong committment to support it (colindixon, 17:25:06)
    20. 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 (colindixon, 17:34:45)
    21. colindixon asks what people think about aggregating all openflow projets under an openflow/ name (like integration) (colindixon, 17:35:04)
    22. 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 (colindixon, 17:35:50)
    23. https://lists.opendaylight.org/pipermail/discuss/2016-May/006522.html tykeal's comments on moving projects (colindixon, 17:36:14)
    24. 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/ (colindixon, 17:36:45)
    25. abhijitkumbhare agrees with rovarga to start small (colindixon, 17:38:30)
    26. colindixon points out that tykeal says above that moving projects would have to change their group IDs for artifacts (colindixon, 17:38:54)
    27. 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 (colindixon, 17:41:53)
    28. colindixon asks under what circumstances (if any) would we allow extensions into the openflow plugin project itself? (colindixon, 17:43:05)
    29. abhijitkumbhare says that some crtieria might be vendor neutrality and system tests (colindixon, 17:44:16)
    30. 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 (colindixon, 17:45:51)
    31. 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 (colindixon, 17:47:26)
    32. it seels like we agreement on moving openflow{plugin,java} and extensions under one group (colindixon, 17:49:35)
    33. 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 (colindixon, 17:50:33)
    34. 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 (colindixon, 17:52:38)
    35. 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 (colindixon, 17:56:18)
    36. rovarga suggests maybe having things need to be standardized or implemented by two or more vendors first, might help wiht that problem (colindixon, 17:57:17)
    37. 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 (colindixon, 17:58:30)


Meeting ended at 17:58:53 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. colindixon (47)
  2. odl_meetbot (4)


Generated by MeetBot 0.1.4.