#opnfv-meeting: OPNFV TSC Meeting

Meeting started by ChrisPriceAB at 14:58:49 UTC (full logs).

Meeting summary

  1. Roll call (ChrisPriceAB, 14:59:16)
    1. Chris Price (ChrisPriceAB, 14:59:38)
    2. Ashiq Khan (Ashiq, 15:00:37)
    3. Uli Kleber (uli_, 15:00:44)
    4. dlenrow (dlenrow, 15:01:24)
    5. Chris Wright (cdub, 15:01:40)
    6. Dirk Kutscher (dku, 15:02:15)
    7. Frank Brockners (frankbrockners, 15:02:58)
    8. I can give a quick update on voting (rpaik, 15:04:14)

  2. minutes approval (cdub, 15:04:42)
    1. no objections to minutes on wiki, approved (cdub, 15:04:56)

  3. agenda bashing (cdub, 15:05:03)
    1. Bryan Sullivan (bryan_att, 15:06:00)
    2. Pranav Mehta (Pranav, 15:07:05)
    3. no agenda changes (cdub, 15:07:35)

  4. board meeting overview (cdub, 15:07:50)
    1. gave overview of sandbox and getting started (cdub, 15:08:32)
    2. mentioned project proposal/definition discussion that chrisw will lead (cdub, 15:09:15)
    3. march'15 release date discussion, unlikely to have simultaneous release plan finalized by end of '14, do we deliver in march, or release later w/ more functionality? (cdub, 15:10:39)
    4. board's feedback was track to march'15 w/ less functionality to get process started rather than wait for more functionality and release later (cdub, 15:11:29)

  5. project proposal process update (cdub, 15:12:46)
    1. project review is given 2 weeks (public review period) (cdub, 15:13:06)
    2. the TSC members are responsible to review during that period and giving feedback _before_ the formal TSC review session (cdub, 15:13:52)

  6. Project proposal process update (ChrisPriceAB, 15:14:16)
    1. cdub: describes that the review of the project creation process has the goal of making it easy for the projects to propose their projects and for the TSC to review (ChrisPriceAB, 15:15:13)
    2. julien ZhangJun_ZTE (julien, 15:15:27)
    3. https://wiki.opnfv.org/project_proposals project types (cdub, 15:15:44)
    4. A change to the wiki was proposed as a simple fix, to clarify that a project proposal should be of only one type (ChrisPriceAB, 15:16:07)
    5. bryan asks if a project that is only a requirement project could produce code (ChrisPriceAB, 15:16:28)
    6. the answer is that a requirements project should not produce code. (ChrisPriceAB, 15:17:05)
    7. bryan states some concern that there is an overhead associated with such a structure we may not want to accomodate (ChrisPriceAB, 15:17:42)
    8. https://wiki.opnfv.org/project_proposals/template proposal template (cdub, 15:18:13)
    9. cdub clarifies that the template was updated to match the project lifecycle document and this is the current description of the process we have (ChrisPriceAB, 15:18:30)
    10. within the discussion there was clarity on how to solve the immediate issues. The longer term problem of reducing the process overhead of the current project lifecycle requires further discussion and development prior to proposing a solution to the TSC. (ChrisPriceAB, 15:19:59)
    11. cdub will send a proposal for this to the list for further discussion. (ChrisPriceAB, 15:20:17)
    12. Pranav agrees with Bryan that a simpler process would be beneficial. (ChrisPriceAB, 15:21:18)
    13. Parviz Yegani (Parviz_, 15:22:13)
    14. bryan suggests a process that allows projects to propose/approve in one week (at least for certain projects (cdub, 15:22:52)
    15. cdub adds that while there is separation of project types they may exist in parallel toward a common goal (ChrisPriceAB, 15:22:54)

  7. upstream software strategy discussion and clarification (cdub, 15:26:22)
    1. which version of upstream do we take, how do we pick, etc? (cdub, 15:26:39)
    2. Thinh Nguyenphu, register (Thinh_, 15:26:50)
    3. how do we define stable? (bryan_att, 15:27:05)
    4. current consensus, latest upstream stable release... (cdub, 15:27:23)
    5. there may be interdependencies that don't always allow for latest of each project (cdub, 15:29:46)
    6. upstream stable release defined simply as "most current versioned upstream release" (cdub, 15:30:32)
    7. we will also need to define what components of the upstream we choose to integrate, and why - we would not necessarily benefit from taking in all components of the upstream for the OPNFV platform unless we agree that the components are "ready" for inclusion in an OPNFV platform release. (bryan_att, 15:31:06)
    8. uli asks why always latest stable, how do we get our updated changes into opnfv platform? (cdub, 15:31:40)
    9. https://wiki.opnfv.org/wiki/opnfv_distribution (julien, 15:34:11)
    10. Parviz asks for clarity on march'15 release containing OpenStack Juno (not Kilo) (cdub, 15:36:11)
    11. becuase Kilo won't exist yet, march'15 would have to be Juno based (cdub, 15:36:29)
    12. chrisprice expects that the a sw version is responsbility of those doing the integration of that sw into the platform (cdub, 15:40:47)
    13. I understand a release to be a heartbeat (meaning regularly shipped on a schedule) collection of the latest stable/mature artifacts of OPNFV as output of projects, filtered by what the TSC agrees is ready and useful as-is to the consumers of the OPNFV platform. It should represent a cohesive product, but we have to get the pipeline moving so initially (bryan_att, 15:42:39)
    14. chriswright suggests that a project should be the sw project (e.g. OpenStack or OpenStack Nova) and that project team owns version choice + testing and automated deployment work. and this project can be home for individual work streams (like ipv6 support) (cdub, 15:42:46)
    15. frankbrockners mentions what is a relase? a line in the sand of things that are known to work together (and could include docs lke requirements) (cdub, 15:43:22)
    16. as we've said repeatedly the SR for our first release will be unique in our communities lifetime because of bootstrap issues. (dlenrow, 15:44:02)
    17. later we will have a steady state, snapshot and probably continuous deliver, but for March we will just get CI working a little (dlenrow, 15:44:40)
    18. Parviz asks if our release is upstream or something that's production quality and deployed to a network (cdub, 15:44:51)
    19. would be upstream, not production/deployed (cdub, 15:45:12)
    20. question we will release a package or source code like openstack? (julien, 15:46:34)
    21. if we narrow the scope of projects as proposed, we can complete some of them by march - e.g. gap analysis projects at least, intended to assess current level of support for certain tested use cases. Upstream code submission should be a stretch goal probably, but remain on the table for those that are already integrated into the upstream. (bryan_att, 15:47:30)
    22. discussion re: upstream process, bringing in a project and finding and issue should get fixes pushed back to upstream (cdub, 15:48:09)
    23. AGREED: that we will focus on using the latest stable releases as a baseline for our OPNFV releases. (ChrisPriceAB, 15:48:45)

  8. release date and composition (ChrisPriceAB, 15:50:36)
    1. ChrisPriceAB states that he does not believe we will be able to run a simultaneous release process by March of 2015 (ChrisPriceAB, 15:50:58)
    2. dlenrow states that we can run a release process, it may not be a simultaneous release process (ChrisPriceAB, 15:51:28)
    3. ashiq states that he thinks it makes sense to have only an integrated platform in the first release, Pranav agrees with this. (ChrisPriceAB, 15:52:40)
    4. upstream are not considered deployable/consumeable directly without commercial distro. First release could/should fix this for our ecosystem (dlenrow, 15:53:39)
    5. A goal should be to give something easy to use as a dev platform for our ecosystem and VF developers (dlenrow, 15:58:32)
    6. ChrisPriceAB proposes that we focus our march release on infrastructure and a basic platform deliverable to prove the infrastructure, CI and Testing projects. (ChrisPriceAB, 15:58:56)
    7. in parallel we continue to develop our simultaneous release process and developmental activities targetted for the second release. (ChrisPriceAB, 15:59:36)
    8. projects should define what they can deliver in the first release, and the TSC should extract that info to assess what's expected and whether it amounts to a release. We don't have to debate this - let's let the projects just define it, and then assess it if needed. (bryan_att, 15:59:36)
    9. bryan_att notes his assumption was that requirements and tests to validate the platform (cdub, 16:03:46)
    10. for requirements projects, if the output of the first release is at least blueprint proposals based upon the assessed capabilities and gaps, that's success. (bryan_att, 16:06:31)
    11. AGREED: The TSC agrees that we will focus our first release on the integration of upstream components into a platform, the development of our continuous integration process, and test projects focused on proving platform and NFV related functionality. (ChrisPriceAB, 16:08:22)
    12. discussing what is in a release? a full distro, a set of git tags, etc (cdub, 16:09:12)
    13. some expressing value of full distro, others expressing value in the integrated/config/deployment (cdub, 16:10:00)
    14. one proposal is "we have a distro and provide meta-releases" (cdub, 16:12:40)
    15. propose we deliver one deployment config of system and then allow additional deployment configs to be delivered at or post-release (dlenrow, 16:14:04)
    16. we should release a cohesive, functional package. Not a compilation of unfiltered projects from the upstream, that may itself not work or require a lot of futzing by users in order to work. (bryan_att, 16:14:38)
    17. it's more than software, for sure - scripts, guidelines, test assets, FAQs, etc also (bryan_att, 16:18:35)
    18. focus on CI/getting started teams to help define this (cdub, 16:23:56)

  9. doctor project proposal review (cdub, 16:24:09)
    1. https://wiki.opnfv.org/doctor/project_proposal (Gerald, 16:24:13)
    2. https://wiki.opnfv.org/doctor/project_proposal (ChrisPriceAB, 16:24:17)
    3. ashiq describes the doctor requirements project, aimed at studying the defining requirements to improve fault management in the VNFI components and an OpenStack based VIM component. (ChrisPriceAB, 16:26:27)
    4. dlenrow asks how this project will remain aligned with the ongoing work in ETSI in this area. (ChrisPriceAB, 16:30:38)
    5. ashiq responds that there is cross collaboration and that alignment is intended to be approached proactively. (ChrisPriceAB, 16:31:12)
    6. dlenrow asks about SDN integration and how this may relate to projects such as OpenDaylight (ChrisPriceAB, 16:31:40)
    7. ashiq responds that OpenStack is the first focus, although the project will accomodate SDN based solutions (ChrisPriceAB, 16:32:21)
    8. AGREED: Doctor requirements project is to be created in OPNFV. (ChrisPriceAB, 16:37:43)
    9. https://wiki.opnfv.org/octopus/project_proposal (rpaik, 16:37:50)

  10. CI project review (ChrisPriceAB, 16:37:53)
    1. https://wiki.opnfv.org/octopus/project_proposal (ChrisPriceAB, 16:38:03)
    2. uli_ described the scope of the octopus CI project, to provide an automated repeatable build and test environment for the OPNFV platform. (ChrisPriceAB, 16:41:52)
    3. dlenrow asks when the project would be ready for approval. (ChrisPriceAB, 16:42:50)
    4. uli_ asnwers that clarity is required from the TSC on what is required. (ChrisPriceAB, 16:43:09)
    5. CI should be something you can drop a buildable project into. If you have a new type of buildable thing that requires extending the CI framework, that work is part of getting your project ready for the CI milestone in a release. (dlenrow, 16:49:49)
    6. need to remove maintainers from the project proposal template (rpaik, 16:57:39)
    7. frankbrockners suggests we have an additional TSC meeting to move project approvals along (dlenrow, 16:59:15)
    8. ACTION: uli_ to finalize the set of committers for the octopus project for final review and approval (ChrisPriceAB, 16:59:21)
    9. I updated the copper project proposal per all the comments I heard on the other projects, FYI - and really need any supporters to add themselves to the contributor list on the wiki! (bryan_att, 16:59:43)
    10. try to get 2 or 3 reviews done in a one hour creation review only call (dlenrow, 17:00:04)
    11. frankbrockers proposed we establish a one hour call to perform project reviews in order to speed up the review process by the TSC. (ChrisPriceAB, 17:00:34)
    12. AGREED: TSC will use the tech call on thursday for TSC project reviews (ChrisPriceAB, 17:03:34)


Meeting ended at 17:03:40 UTC (full logs).

Action items

  1. uli_ to finalize the set of committers for the octopus project for final review and approval


Action items, by person

  1. uli_
    1. uli_ to finalize the set of committers for the octopus project for final review and approval


People present (lines said)

  1. ChrisPriceAB (47)
  2. cdub (41)
  3. dlenrow (21)
  4. bryan_att (13)
  5. dneary (6)
  6. collabot (6)
  7. frankbrockners (6)
  8. julien (4)
  9. Ashiq (4)
  10. Gerald (3)
  11. rpaik (3)
  12. uli_ (2)
  13. Pranav (2)
  14. TapioT (2)
  15. Parviz_ (2)
  16. dku (2)
  17. margaret__ (2)
  18. Thinh_ (1)
  19. Hui (1)
  20. aricg (1)
  21. Yuriy (1)
  22. Torsten_ (1)
  23. Wenjing (1)
  24. (DOCOMO) (0)


Generated by MeetBot 0.1.4.