14:58:49 #startmeeting OPNFV TSC Meeting 14:58:49 Meeting started Tue Dec 2 14:58:49 2014 UTC. The chair is ChrisPriceAB. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:58:49 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:16 #topic Roll call 14:59:29 Please for TSC members #info in to the IRC chanel 14:59:38 #info Chris Price 15:00:37 #info Ashiq Khan 15:00:44 #info Uli Kleber 15:01:24 #info dlenrow 15:01:40 #info Chris Wright 15:01:54 #chair dlenrow 15:01:54 Current chairs: ChrisPriceAB dlenrow 15:02:00 #chair cdub 15:02:00 Current chairs: ChrisPriceAB cdub dlenrow 15:02:15 #info Dirk Kutscher 15:02:58 #info Frank Brockners 15:03:12 #nick Gerald (DOCOMO) 15:03:17 #chair frankbrockners 15:03:17 Current chairs: ChrisPriceAB cdub dlenrow frankbrockners 15:03:35 Quick question: Do we know how voting works for our meetbot by now? 15:04:14 #info I can give a quick update on voting 15:04:42 #topic minutes approval 15:04:56 #info no objections to minutes on wiki, approved 15:05:03 #topic agenda bashing 15:05:29 Voting is provided by openstack's fork of meetbot, it's not yet installed. (it's on my task list) 15:05:37 CP your volume isn't great, hard to hear 15:06:00 #info Bryan Sullivan 15:07:05 #info Pranav Mehta 15:07:35 #info no agenda changes 15:07:50 #topic board meeting overview 15:08:32 #info gave overview of sandbox and getting started 15:09:15 #info mentioned project proposal/definition discussion that chrisw will lead 15:10:39 #info 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? 15:10:54 #join Tapio Tallgren 15:11:29 #info board's feedback was track to march'15 w/ less functionality to get process started rather than wait for more functionality and release later 15:12:46 #topic project proposal process update 15:13:06 #info project review is given 2 weeks (public review period) 15:13:52 #info the TSC members are responsible to review during that period and giving feedback _before_ the formal TSC review session 15:14:16 #topic Project proposal process update 15:15:13 #info 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 15:15:27 #info julien ZhangJun_ZTE 15:15:44 #link https://wiki.opnfv.org/project_proposals project types 15:16:07 #info A change to the wiki was proposed as a simple fix, to clarify that a project proposal should be of only one type 15:16:28 #info bryan asks if a project that is only a requirement project could produce code 15:17:05 #info the answer is that a requirements project should not produce code. 15:17:42 #info bryan states some concern that there is an overhead associated with such a structure we may not want to accomodate 15:18:13 #link https://wiki.opnfv.org/project_proposals/template proposal template 15:18:30 #info cdub clarifies that the template was updated to match the project lifecycle document and this is the current description of the process we have 15:19:59 #info 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. 15:20:17 #info cdub will send a proposal for this to the list for further discussion. 15:21:18 #info Pranav agrees with Bryan that a simpler process would be beneficial. 15:22:13 #info Parviz Yegani 15:22:52 #info bryan suggests a process that allows projects to propose/approve in one week (at least for certain projects 15:22:54 #info cdub adds that while there is separation of project types they may exist in parallel toward a common goal 15:26:22 #topic upstream software strategy discussion and clarification 15:26:39 #info which version of upstream do we take, how do we pick, etc? 15:26:50 #info Thinh Nguyenphu, register 15:27:05 #info how do we define stable? 15:27:23 #info current consensus, latest upstream stable release... 15:29:46 #info there may be interdependencies that don't always allow for latest of each project 15:30:32 #info upstream stable release defined simply as "most current versioned upstream release" 15:31:06 #info 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. 15:31:40 #info uli asks why always latest stable, how do we get our updated changes into opnfv platform? 15:33:56 latest release refer to "opnfv release" or "openstack/ODL release"? 15:34:11 #link https://wiki.opnfv.org/wiki/opnfv_distribution 15:36:11 #info Parviz asks for clarity on march'15 release containing OpenStack Juno (not Kilo) 15:36:29 #info becuase Kilo won't exist yet, march'15 would have to be Juno based 15:40:47 #info chrisprice expects that the a sw version is responsbility of those doing the integration of that sw into the platform 15:42:39 #info 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 15:42:39 it might be pretty sparse. 15:42:46 #info 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) 15:43:22 #info 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) 15:44:02 #info as we've said repeatedly the SR for our first release will be unique in our communities lifetime because of bootstrap issues. 15:44:40 #info later we will have a steady state, snapshot and probably continuous deliver, but for March we will just get CI working a little 15:44:51 #info Parviz asks if our release is upstream or something that's production quality and deployed to a network 15:45:12 #info would be upstream, not production/deployed 15:45:38 question: Do we need a SR for the first release? To me the discussion sounds like we'd like to choose from a set of upstream projects and components - and get them integrated and tested - which is not necessarily the same as a SR. 15:45:45 My proposal is that CI startup and test projects are probably all we should target (can have stretch goals) for March 15:46:20 @dlenrow: What would you release in March then? 15:46:20 frankbrockners: Error: "dlenrow:" is not a valid command. 15:46:33 rofl 15:46:34 #info question we will release a package or source code like openstack? 15:47:01 frankbrockners: agree with you. We release some stuff that deploys the upstream artifacts into a development environment for creating/testing VNFs 15:47:30 #info 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. 15:48:09 #info discussion re: upstream process, bringing in a project and finding and issue should get fixes pushed back to upstream 15:48:45 #agree that we will focus on using the latest stable releases as a baseline for our OPNFV releases. 15:49:36 frankbrockners: We can have a first release, not a first SR. SR will come post-bootstrap. 15:50:16 dlenrow: Sounds like the most reasonable way forward. I.e. do Rel#1 w/o SR - do SR thereafter 15:50:36 #topic release date and composition 15:50:58 #info ChrisPriceAB states that he does not believe we will be able to run a simultaneous release process by March of 2015 15:51:12 deployment tools for the upstream artifacts are the primary value add in release 1 IMHO 15:51:28 #info dlenrow states that we can run a release process, it may not be a simultaneous release process 15:52:40 #info ashiq states that he thinks it makes sense to have only an integrated platform in the first release, Pranav agrees with this. 15:53:39 #info upstream are not considered deployable/consumeable directly without commercial distro. First release could/should fix this for our ecosystem 15:58:32 #info A goal should be to give something easy to use as a dev platform for our ecosystem and VF developers 15:58:56 #info ChrisPriceAB proposes that we focus our march release on infrastructure and a basic platform deliverable to prove the infrastructure, CI and Testing projects. 15:59:36 #info in parallel we continue to develop our simultaneous release process and developmental activities targetted for the second release. 15:59:36 #info 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. 16:01:38 But I think then we will keep debating of what the first release should be. 16:03:33 dropping off call 16:03:40 * ChrisPriceAB thanks dave 16:03:40 Conflicting meeting 16:03:46 #info bryan_att notes his assumption was that requirements and tests to validate the platform 16:03:51 dneary: cheers 16:04:01 ChrisPriceAB, cdub: You're welcome. 16:06:31 #info 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. 16:06:39 bryan_att: thanks 16:06:58 agree Bryan. 16:07:09 need to drop off also - but bryan of course has the lead. 16:07:33 margaret__: thanks, cya later 16:08:22 #agree 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. 16:08:54 +1 distro-like usability for collective "system" 16:09:12 #info discussing what is in a release? a full distro, a set of git tags, etc 16:10:00 #info some expressing value of full distro, others expressing value in the integrated/config/deployment 16:12:40 #info one proposal is "we have a distro and provide meta-releases" 16:14:04 #info propose we deliver one deployment config of system and then allow additional deployment configs to be delivered at or post-release 16:14:38 #info 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. 16:18:35 #info it's more than software, for sure - scripts, guidelines, test assets, FAQs, etc also 16:23:56 #info focus on CI/getting started teams to help define this 16:24:09 #topic doctor project proposal review 16:24:13 https://wiki.opnfv.org/doctor/project_proposal 16:24:17 #link https://wiki.opnfv.org/doctor/project_proposal 16:26:27 #info 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. 16:30:38 #info dlenrow asks how this project will remain aligned with the ongoing work in ETSI in this area. 16:31:12 #info ashiq responds that there is cross collaboration and that alignment is intended to be approached proactively. 16:31:40 #info dlenrow asks about SDN integration and how this may relate to projects such as OpenDaylight 16:32:03 * cdub has to drop 16:32:21 #info ashiq responds that OpenStack is the first focus, although the project will accomodate SDN based solutions 16:32:37 * ChrisPriceAB thanks cdub 16:34:30 links in the project_proposal Wiki page are correct 16:36:26 #startvote Vote to create the requirement project "doctor" for fault management requirements. (+1, 0 ,-1) 16:36:28 #vote +1 16:36:29 #vote +1 16:36:30 #vote +1 16:36:35 #vote +1 16:36:35 #vote +1 16:36:36 #vote +1 16:36:37 #vote +1 16:36:38 #vote +1 16:36:41 #vote +1 16:36:41 #vote +1 16:36:44 #vote +1 16:36:49 Congratulations Doctor 16:36:57 #endvote 16:37:02 Thank you all. 16:37:07 #vote +1 16:37:43 #agree Doctor requirements project is to be created in OPNFV. 16:37:50 #link https://wiki.opnfv.org/octopus/project_proposal 16:37:50 #vote +1 16:37:53 #topic CI project review 16:38:03 #link https://wiki.opnfv.org/octopus/project_proposal 16:41:52 #info uli_ described the scope of the octopus CI project, to provide an automated repeatable build and test environment for the OPNFV platform. 16:42:50 #info dlenrow asks when the project would be ready for approval. 16:43:09 #info uli_ asnwers that clarity is required from the TSC on what is required. 16:46:23 Back on the call 16:49:49 #info 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. 16:50:09 CI doesn't depend on Oscar, Oscar depends on CI 16:57:39 #info need to remove maintainers from the project proposal template 16:59:15 #info frankbrockners suggests we have an additional TSC meeting to move project approvals along 16:59:21 #action uli_ to finalize the set of committers for the octopus project for final review and approval 16:59:37 Is that in addition to the "technical project review" meetings? 16:59:43 #info 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! 17:00:04 #info try to get 2 or 3 reviews done in a one hour creation review only call 17:00:30 dneary: creation review is differteent than the project reviews 17:00:31 sorry, gotta drop 17:00:34 #info frankbrockers proposed we establish a one hour call to perform project reviews in order to speed up the review process by the TSC. 17:00:52 I'm concerned that we have too many calls 17:01:25 dneary: TSC trying to stop being bottleneck to projects 17:01:44 +1 hijack TWS call 17:03:11 sleepy 17:03:34 #agree TSC will use the tech call on thursday for TSC project reviews 17:03:40 #endmeeting