Re: [onap-tsc] Planning for ONAP TSC Elections
Hi Phil, +1 to the proposal. I would also like to volunteer in the WG. Thanks, Zhaoxing 原始邮件 发件人： ; 收件人： ; 日 期 ：2017年12月14日 08:03 主 题 ：[onap-tsc] Planning for ONAP TSC Elections ___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc Hello ONAP TSC Members: As documented in the ONAP Project Charter, the TSC is tasked with figuring out how to populate the TSC in a meritocratic manner beginning 12 months after the project launch, which was March 2017. Hence it is time to start planning this transition. To kick this process off, I have the following suggestions: - Given that March 2018 is in the middle of the Beijing release cycle, I suggest we postpone the TSC election until directly after the Beijing release in late May. We should discuss and approve our method of populating the TSC by the end of March, but not actually execute it until late May or early June. Please let me know if you think this is a good or bad idea. - I suggest we form a small workgroup to create an initial proposal for discussion with the broader TSC. Some topics to consider when architecting the TSC makeup include: - Constituencies. Are there different constituencies that need representation on the TSC? - PTLs. Having an election of PTLs to populate the TSC one possible way to do it. These PTLs may be from different constituencies, or just At-Large. - Committers-At-Large (CALs). Some seats can come from the committer community at large. - Particular Roles. Possibly have the PTL from the Integration Team, or the Release Manager as voting members of the TSC as an example of "special" roles that should have TSC representation. - Company Caps - To ensure that a single company does not have too much voting power within the TSC, a limit (usually defined as a percentage) is imposed on how many TSC members can come from the same organization (or affiliated organization). - TSC size. Common guidance is to keep the TSC size somewhere between 7 and 19. 11,13, and 15 are common sizes. Depending on how the TSC is populated the size may vary or may be static. Please let me know your thoughts. If you think a workgroup to put an initial proposal together is a good idea, please indicate that. If you think we should have a few open discussions to set an initial direction please indicate that. If a workgroup seems reasonable, and you would like to participate in that group please indicate that as well. I look forward to the discussion. Thanks, Phil. -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] 答复: [arch] Corrections for the architecture document.
+1 Agree to these changes except the modification of P7, the original version of P7 is already clear Best regards Zhaoxing Original Mail Sender: ; To: ; CC: ; ; Date: 2017/11/24 09:19 Subject: [onap-tsc] 答复: [arch] Corrections for the architecture document. Hello Agree to the update of P9,P10,P11. And also agree to remove D2 term. But I don’t think the update to P7 is more suitable, the original version seems better. Best regards 发件人: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 代表 eric.deb...@orange.com 发送时间: 2017年11月24日 4:04 收件人: onap-tsc@lists.onap.org; onap-...@lists.onap.org 主题: [onap-tsc] [arch] Corrections for the architecture document. Hello Please find some corrections for the Architecture document https://www.onap.org/wp-content/uploads/sites/20/2017/11/ONAP_CaseSolution_Architecture_FNL.pdf As noticed by Nermin, the D2 term should be removed from Figure 1 P7. Controllers I think the VF-C definition is not exact according to existing R1 code. “Also, the Virtual Function Controller (VF-C) provides an ETSI NFV compliant NFV-O function, and is responsible for lifecycle management of virtual services and the associated physical COTS server infrastructure. VF-C provides a generic VNFM capability but also integrates with external VNFMS and VIMs as part of a NFV MANO stack.” We propose to replace by “The Virtual Function Controller (VF-C) is responsible for managing the lifecycle of VNF when this cannot be achieved by other components of the ONAP architecture and for managing the lifecycle of network services that comprise at least one of such VNF. It can also processes fault and performance management events to trigger the ONAP closed loops.“ P9 vCPE use-case “Similarly, ONAP uses the APP -C component to manage the virtualization infrastructure.” ð “Similarly, ONAP uses the APP -C component to manage the VNF lifecycle“ P10&11 References/Links to the use case white papers are missing “Read the Residential vCPE Use Case with ONAP whitepaper to learn more.” “Read the VoLTE Use Case with ONAP whitepaper to learn more.” Best Regards Eric _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] ona-user mailing list?
+1 Zhaoxing Original Mail Sender: ; To: ; ; ; Date: 2017/11/23 12:19 Subject: Re: [onap-tsc] ona-user mailing list? +1 Lingli From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Dhananjay Pavgi Sent: 2017年11月22日 16:20 To: Kanagaraj Manickam ; onap-tsc@lists.onap.org Subject: Re: [onap-tsc] ona-user mailing list? Good idea, Kanagaraj. +1. thanks & regards, Dhananjay Pavgi +91 98220 22264 From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam Sent: Wednesday, November 22, 2017 1:48 PM To: onap-tsc@lists.onap.org Subject: [onap-tsc] ona-user mailing list? Dear TSC team, When user starts to use the ONAP Amsterdam version and they would need an forum to discuss among the user communities to discuss about ONAP usage related issues. So, shall we create new mailing list ‘onap-user’, to address it? This would be similar to onap-discuss, used by developers community. Thank you. Regards Kanagaraj M *** 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！** *** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *** Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra. ___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] Vote on Date & Location of Next ONAP Developer Face ToFace
[VOTE] +1 Original Mail Sender: To: Date: 2017/08/03 05:49 Subject: [onap-tsc] Vote on Date & Location of Next ONAP Developer Face ToFace Hello ONAP TSC Members: As was mentioned at the last TSC meeting, Nokia and Orange have offered to host the next ONAP Developer Face to Face meeting the week of September 25th, 2017 at the Nokia Paris-Saclay facility approximately 25 Kilometers south west of the Paris Orly airport. We will have access to an auditorium that holds 200 people along with several conference/break-out rooms. We are still finalizing the specific days of the event, but I would like to have the TSC approve this time/week, and location so that attendees who need visas can begin the process of getting them. Therefore, please provide your vote via email to the following resolution: Shall the TSC approve the next ONAP Developer Face to Face meeting to be held the week of September 25th, at the Nokia facility located in Paris-Saclay, France? +1, 0, -1 TSC Members, please provide your vote at your earliest opportunity. If we reach an affirmative vote on this prior to the TSC meeting tomorrow, we'll simply make that announcement during the meeting. If we do not reach an affirmative vote, we will discuss this topic and vote on it in the meeting tomorrow. Thanks in advance for your response. Best, Phil. -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] TSC VOTE on Repos for AAI, AAF, Modeling & MSB
Yes. "+1 All" 原始邮件 发件人： 收件人：孟照星10024238 抄送人： 日 期 ：2017年07月28日 01:10 主 题 ：Re: [onap-tsc] TSC VOTE on Repos for AAI, AAF, Modeling & MSB Hi Zhaoxing, please verify that your response was intended as a "+1 All” Thanks! Best Regards, -kennyKenny Paul, Technical Program Managerkpaul@linuxfoundation.org510.766.5945 On Jul 27, 2017, at 5:25 AM, meng.zhaoxi...@zte.com.cn wrote: [VOTE] +1 发件人： 收件人： 日 期 ：2017年07月23日 02:49 主 题 ：[onap-tsc] TSC VOTE on Repos for AAI, AAF, Modeling & MSB As mentioned we have several repository requests queued up. Gildas has reviewed these and feels the requestors have done their due diligence regarding the data needed. Please vote for each one individually OR respond with a (+1, 0, -1) “ALL” to approve or reject all requests —— VOTE to approve the AAF Project's Requests for the creation of an incremental repository (+1, 0 -1) Components Name Components Repository name Maven Group ID Components Description luaplugin aaf/luaplugin org.onap.aaf.luaplugin A lua plugin to integrate AAF with MSB, which provides centralized auth features at the API Gateway. VOTE to approve the MSB Project's Requests for the creation of two incremental repositories (+1, 0 -1) Components Name Components Repository name Maven Group ID Components Description java-sdk msb/java-sdk org.onap.msb.sdk Provides a JAVA SDK for rapid microservices development, including service registration, service discovery, request routing, load balancing, retry, etc. swagger-sdk msb/swagger-sdk org.onap.msb.swagger-sdk Swagger sdk helps to generate swagger.json and java client sdk during the build time, it also helps to provide the swagger.json at the given URI in the run time. VOTE to approve the A&AI Project's Requests for the creation of two incremental repositories (+1, 0 -1) Components NameComponents Repository NameMaven Group IDComponents Discriptionesr-serveraai/esr-serverorg.onap.aai.esr-serverESR backend, mainly include the function of external system reachable check and data pretreatmentesr-guiaai/esr-guiorg.onap.aai.esr-guiExternal system management ui VOTE to approve the Modeling Subcommittee’s requests for the creation of an incremental repository within the Modeling Project’s structure (+1, 0 -1) Components Name Components Repository name Maven Group ID Components Description modelspec modeling/modelspec org.onap.modeling.modelspec The repository for modeling specification published by modeling subcommittee Best Regards, -kennyKenny Paul, Technical Program Managerkpaul@linuxfoundation.org510.766.5945___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] TSC VOTE on Repos for AAI, AAF, Modeling & MSB
[VOTE] +1 原始邮件 发件人： 收件人： 日 期 ：2017年07月23日 02:49 主 题 ：[onap-tsc] TSC VOTE on Repos for AAI, AAF, Modeling & MSB As mentioned we have several repository requests queued up. Gildas has reviewed these and feels the requestors have done their due diligence regarding the data needed. Please vote for each one individually OR respond with a (+1, 0, -1) “ALL” to approve or reject all requests —— VOTE to approve the AAF Project's Requests for the creation of an incremental repository (+1, 0 -1) Components Name Components Repository name Maven Group ID Components Description luaplugin aaf/luaplugin org.onap.aaf.luaplugin A lua plugin to integrate AAF with MSB, which provides centralized auth features at the API Gateway. VOTE to approve the MSB Project's Requests for the creation of two incremental repositories (+1, 0 -1) Components Name Components Repository name Maven Group ID Components Description java-sdk msb/java-sdk org.onap.msb.sdk Provides a JAVA SDK for rapid microservices development, including service registration, service discovery, request routing, load balancing, retry, etc. swagger-sdk msb/swagger-sdk org.onap.msb.swagger-sdk Swagger sdk helps to generate swagger.json and java client sdk during the build time, it also helps to provide the swagger.json at the given URI in the run time. VOTE to approve the A&AI Project's Requests for the creation of two incremental repositories (+1, 0 -1) Components NameComponents Repository NameMaven Group IDComponents Discriptionesr-serveraai/esr-serverorg.onap.aai.esr-serverESR backend, mainly include the function of external system reachable check and data pretreatmentesr-guiaai/esr-guiorg.onap.aai.esr-guiExternal system management ui VOTE to approve the Modeling Subcommittee’s requests for the creation of an incremental repository within the Modeling Project’s structure (+1, 0 -1) Components Name Components Repository name Maven Group ID Components Description modelspec modeling/modelspec org.onap.modeling.modelspec The repository for modeling specification published by modeling subcommittee Best Regards, -kennyKenny Paul, Technical Program Managerkpaul@linuxfoundation.org510.766.5945___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] TSC Members- Action Required Approval of changes to thePortal Platform Project
[VOTE] +1 Original Mail Sender: To: CC: Date: 2017/07/15 08:05 Subject: [onap-tsc] TSC Members- Action Required Approval of changes to thePortal Platform Project In an effort to try and minimize the level of email traffic on this list this approval was originally attempted this as a CIVS poll. Unfortunately quorum was not achieved. As such I’m falling back to an email vote to provide members that did not participate the opportunity to do so. From the TSC Charter: 3.2.2 CommitterLifecycle3.2.2.1 Adding CommittersInitial Committers for a project will be specified at project creation Committer rights for a project are earned via contribution and community trust. Committers for a project select and vote for new Committers for that project, subject to TSC approval. New Committers for a project should have a demonstrable established history of meritocratic contributions. TSC approval is requested for the following changes to the ONAP Portal Platform Project: https://wiki.onap.org/display/DW/Portal+Platform+Project - Add "Sunder Tatta”(sta...@research.att.com) as a committer (Only a single committer currently on the project) - Add a new repository “portal/sdk” ACTION: I approve the committer addition (Vote +1, 0, -1) I approve the repository addition (Vote +1, 0, -1) Votes already cast are all in favor of approving both the committer and repository additions. mg1...@att.com:1jamil.cha...@orange.com:1meng.zhaoxi...@zte.com.cn:1aayush.bhatna...@ril.com:1stephen.terr...@ericsson.com:1ranny.ha...@nokia.com:1 Best Regards, -kennyKenny Paul, Technical Program Managerkpaul@linuxfoundation.org510.766.5945___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] Irregularities in the Use Case SubcommitteeChair Election
Hi, +1 Transparency and respecting rules helps building fairness and trust which is key principle for any healthy open source community. We expect TSC or LF could release some kind of warning on those who did not respecting rules no matter intentionally or unintentionally. Also we expect TSC can solve the committer issue as quickly as possible to remove the obstacle for those projects impacted. Thanks, Zhaoxing. Original Mail Sender: To: CC: Date: 2017/07/10 07:58 Subject: Re: [onap-tsc] Irregularities in the Use Case SubcommitteeChair Election Phil and all, I also agree that it is important to make up for the loopholes in the TSC charter, but I think the correction of irregularities is the key to building a truly trusting environment. Without this basic openness and fairness, the prosperity and success of the open source community is at high risk. Since when the voting is initiated, it was made clear that the vote would be carried out with reference to a specific version of membership. And hence all the new members, which China Mobile added later, did not ask to vote, but planned to participate in subsequent discussions. I strongly urge the LF to clarify the voting results, remove five votes that did not meet the clearly stated qualifications in the voting initiation email therefore gained unfair advantage to those who obeyed the regulations, and make the necessary public warning to the subject (individual or company). Firstly, it is normal and healthy that there must be different opinions in any open organization composed of many members. Therefore, it is necessary to agree as far as possible on clear and unambiguous rules to specify how to reach consensus when the dispute arises, including the formation of the rule itself, the election of officials, the resolution on a specific topic, and so on. Second, one has to admit that any pre-established rules or statutes are not likely to enumerate all the possible situations in a complete reality. In other words, there is always a gray area where the rule cannot be covered. It is also a normal and inevitable phenomenon that someone has taken advantage of these loopholes or gray areas. When it is found that such a situation has occurred and that it should be stopped in the future, it is necessary but not sufficient to prevent the recurrence of such a phenomenon by simply amending the rule to make up for deficiencies in the rules. Third, the respect for the rule itself and the faithful implementation of the resolution of a group formed by a process that is in accordance with the rules are the premises of any rule. In an organization that is composed of complex members, it is essential that its members, especially its leadership, in the process of practice, show respect the existing rules rather than disrupt the implementation of the rules. Especially if unacceptable violations to existing rules/agreement happens, if no correction is made, but blindly blame and amend the rule itself, even if they have the perfect rules in theory (that covers every situation in reality), these rules will be useless. Fourth, In the handling of this specific case, the core of the problem cannot be solved and the undesirable behavior will be undoubtedly happening again, if we only focus on the amendments to the TSC Charter, rather than emphasizing and establishing the spirit of the community to really respect and defend TSC Charter. Who will respect and implement the rules/agreement, if the violation of the rules will not be subject to any necessary warning, and once there is a problem, in any case can modify the existing rules at any time? Therefore, it is my firm belief that the correction of irregularities is the key to truly building a trust environment. Without this basic openness and fairness, the prosperity and success of the open source community will be at high risk. With this incident, I am personally involved and deeply troubled. As a candidate, I am under no obligation to accept unwarranted suspicion. I believe that all members who were voting in accordance with the rules regularly have the right to call for rectification of their own respect for the rules. Therefore, I strongly call for resolute redress of those violations of the rules and the necessary public warnings of such behavior. We need more transparency and fairness in this community. Thanks, Lingli From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Phil Robb Sent: 2017年7月7日 23:47 To: Ed Warnicke Cc: onap-tsc Subject: Re: [onap-tsc] Irregularities in the Use Case Subcommittee Chair Election Hi Ed and Bob: Given that the Subcommittees we are talking about are technical subcommittees serving at the pleasure of the TSC, I suggest the TSC own setting the parameters for voting and company representation within these sub
Re: [onap-tsc] sdc committers
Hi Mazin, Thank you for your response! My concern is if we followed a proper principle to remove the committers from an approved project abiding by TSC charter and open source spirit. I believe TSC charter does not grant PTLs the privilege to move committers to contributor list directly. I do not recall that TSC has made a decision to ask the PTL to clean up the committer list at this point of time. I remember in TSC meeting people suggested we can look back and clear the committer list based on their contributions in Amsterdam development after we reached our Amsterdam goal. Thanks, Zhaoxing 原始邮件 发件人： 收件人：袁越10008526 抄送人：孟照星10024238 日 期 ：2017年07月06日 19:26 主 题 ：Re: [onap-tsc] sdc committers Yuan Yue, I have not examined this particular project, but the TSC and I have requested last week during the review phase of projects for R1, that the PTLs clean up the list of committers to 3-5, as some are more qualified to be contributors than committers. We have projects with 16-20 committers and 2-3 contributors. PTLs should work with their project team to clean-up the list to a core set of committers but should do it in total transparency and openness. If the TSC needs to provide clearer guidelines then we can discuss today in our TSC Meeting. thanks Mazin On Jul 6, 2017, at 4:42 AM, yuan@zte.com.cn wrote: Hi Michael and Phil, I wish this is just an unintentional mistake during synchronizing information between "approved SDC proposal page" to "Resources and Repositories" in the wiki page. Otherwise I would be greately confused on the pratice of removing committer from an approved project acording to the procedure we have defined on TSC Charter: A Committer for a project who is disruptive, or has been inactive on that project for an extended period (e.g., six or more months) may have his or her Committer status revoked by the project’s Project Technical Leader (PTL) or by super-majority vote of the project’s committers. The Project Technical Leader is responsible for informing the Technical Steering Committee (TSC) of any committers who are removed or resign. Is there any explanation on the issue Zhaoxing mentioned in his mail? Best Regards, Yuan Yue ___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=zagCM6lrm4jcHVIcirLmNorTBnCLgbojm4GVc3NWGnA&s=WzM6PSwQz7jZ2SxUp_oMzcrP2JB3z4oWonomCFpPfPg&e= 发件人：孟照星10024238 收件人： 抄送人： 日 期 ：2017年07月06日 14:45 主 题 ：[onap-tsc] sdc committers Hi Michael, I noticed that some of the committers have been removed from Resources and Repositories even though they're listed as committer in the approved SDC proposal page . There is a guideline from TSC about project participants, for community diversity, a project is encouraged to have at least three companies involved, Currently only 2 in SDC. Given that ZTE has seed codes for SDC listed in the approved proposal page for Catalog, workflow designer and VNF designer, I think the committers from ZTE should also be listed at the Resources and Repositories page. Thanks and Regards, Zhaoxing___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] [onap-discuss] [modeling] Please vote for chairperson of ModelingSubcommittee
+1 原始邮件 发件人： 收件人： 日 期 ：2017年07月07日 11:57 主 题 ：[onap-discuss] [modeling] Please vote for chairperson of ModelingSubcommittee Hello, Modelling members, There is only one candidate for modeling subcommittee: Hui Deng If you support Please help to vote “+1”, If you are neutral, please vote “0”, If you don’t please respond “-1” Members are listed here: https://wiki.onap.org/display/DW/Members Thanks a lot DENG Hui___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] A&AI Project needs new repos for microservices
+1 原始邮件 发件人： 收件人： 抄送人： 日 期 ：2017年07月06日 00:27 主 题 ：[onap-tsc] A&AI Project needs new repos for microservices Dear ONAP TSC Members, The A&AI team would like to request permission to add 3 new repositories for 2 new microservices and a new graph database abstraction library for the Amsterdam release. The repos will be called: aai/champ aai/gizmo aai/babel A&AI’s rationale for creating these separate repos as opposed to using a subdirectory under an existing repo is as follows: it is the convention to create a separate git repository for each microservice and library as is demonstrated by the microservices currently part of the AAI project. The advantages of separate repos (as opposed a single repo containing multiple microservices) is the ability to manage access rights for each microservice. Otherwise a user with write permissions to the “common” microservice repo could accidentally (or intentionally) make change to another microservice. Please let me know if further clarification is needed. Thank you for your attention, Jimmy Forsyth A&AI PTL___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
[onap-tsc] Reply：TSC Meeting Minute Approvals
Approval of the TSC meeting minutes from June 29, 2017 (Vote +1, 0 -1) : +1 Approval of the TSC meeting minutes from June 22, 2017 (Vote +1, 0 -1) : +1 Approval of the TSC meeting minutes from June 15, 2017 (Vote +1, 0 -1) : +1 Sent from my zMail Original Message From: KennyPaul To:Alla Goldner mg1...@att.com Sauvageau, David Deng xiexj...@chinatelecom.cn Ed Warnicke Stephen Terrill Amir Levy Christopher Donley (Chris) Jason Hunt rajesh.gadi...@intel.com Haiby, Ranny (Nokia - US/San Jose USA) jamil.cha...@orange.com aayush.bhatna...@ril.com Dhananjay Pavgi Xinhui Li susana.saba...@vodafone.com mengzhaoxing10024238 Cc:onap-tsc Date: 2017-07-06 19:29:30 Subject:TSC Meeting Minute Approvals TSC Members: As agreed upon at last week’s TSC meeting we will pursue meeting minute approvals via email or a poll in order to maximize the amount of time available during the TSC meeting. Initially there are several weeks worth of meeting minutes that require approval. I have consolidated the approval requests into a single message in an effort to limit the volume of email generated. Going forward this will be done on a weekly basis. Please provide a response to each line with a +1, 0, -1 vote Approval of the TSC meeting minutes from June 29, 2017 (Vote +1, 0 -1) : Approval of the TSC meeting minutes from June 22, 2017 (Vote +1, 0 -1) : Approval of the TSC meeting minutes from June 15, 2017 (Vote +1, 0 -1) : Thank you. Best Regards, -kenny Kenny Paul, Technical Program Manager kp...@linuxfoundation.org 510.766.5945___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
[onap-tsc] sdc committers
Hi Michael, I noticed that some of the committers have been removed from Resources and Repositories even though they're listed as committer in the approved SDC proposal page . There is a guideline from TSC about project participants, for community diversity, a project is encouraged to have at least three companies involved, Currently only 2 in SDC. Given that ZTE has seed codes for SDC listed in the approved proposal page for Catalog, workflow designer and VNF designer, I think the committers from ZTE should also be listed at the Resources and Repositories page. Thanks and Regards, Zhaoxing___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] TSC MEMBERS Usecase Subcommittee Procedural Issue
Hi Kenny, It seems to me that this minor typo simply does not affect nominations and elections because First, all nominees are not members of the open labs, but members of the usecase subcommittee. Hence the nomination is not affected. Second, the vote is also sent to the members of usecase subcommittee, and did not send open labs members. Hence the election is not affected. Therefore, the first option " Accept the clerical error and uphold the results of the election" sounds good for me. Zhaoxing 原始邮件 发件人： 收件人： 日 期 ：2017年07月04日 07:32 主 题 ：[onap-tsc] TSC MEMBERS Usecase Subcommittee Procedural Issue TSC Members, I have identified what appears to be a simple copy/paste error in the original June 26th call for nominations for the Usecase Subcommittee Chair position that puts the current election in question. Original notice: https://lists.onap.org/pipermail/onap-discuss/2017-June/001894.html The text in question reads, "Any member of the Open Lab Subcommittee may run for this position”, rather than saying “Any member of the Usecase Subcommittee…" The net results is that the candidates on the ballot failed to meet this nomination requirement as it is written. This issue was not discovered until after the nomination phase was closed and the election phase was in progress. Voting in this election is scheduled to close at 8AM Pacific on July 5th. I see three logical actions the TSC could take in this situation, but perhaps there are others: - Accept the clerical error and uphold the results of the election - Reopen the nomination and election process with a shortened time line - Repoen the nomination and election process with the typical time line (~8-10 business days) I will withhold the results of the election pending a decision on how to proceed coming out of Thursday's TSC meeting . Best Regards, -kennyKenny Paul, Technical Program Managerkpaul@linuxfoundation.org510.766.5945___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
[onap-tsc] Re： Corrective Action on Approved Project Proposals
+1 发自我的zMail 原始邮件 发件人: KennyPaul 收件人:onap-tsc 日期: 2017-06-30 03:12:59 主题:[onap-tsc] Corrective Action on Approved Project Proposals TSC Members: The following are discrepancies and/or change requests in the approved versions of the Project Proposals have been identified during project infrastructure set up, which warrants your attention. To minimize email traffic I have consolidated these into a single message for your review. It is my recommendation that we pursue the necessary corrective action to maintain forward momentum. In the event that any TSC member feels that any one of these items warrants further consideration/discussion please let me know and I will see that we address it a more formal fashion. ACTION REQUIRED: A +1, 0, -1 vote in response to this email will be deemed sufficient to cover all of these cases. Please let me know if you have any questions. Project Descrepancy / Requested change Corrective Action Command Line Interface Jira naming conflict with the Portal project changing Jira Project name from PORTAL to CLI and Jira Prefix and Mailing list to CLI University conflicting repo naming within the different sections of the Proposal setting repo name to onapuniversity Software Defined Network Controller - list of commiter names changed - addition of 2 repositories org.onap.sdnc/architecture org.onap.sdnc/features Accept requested changes Modeling repository name change request- remove “modeling” and replace with repos named “toscaparsers” and “yangvalidators” Accept requested changes MultiVIM/cloud: Addition of 1 repository - windriver Accept requested change Best Regards, -kenny Kenny Paul, Technical Program Manager kp...@linuxfoundation.org 510.766.5945___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] Approval of Prior Meeting Minutes
+1 原始邮件 发件人： 收件人： 日 期 ：2017年06月20日 16:52 主 题 ：Re: [onap-tsc] Approval of Prior Meeting Minutes +1 Original Message Subject: [onap-tsc] Approval of Prior Meeting Minutes From: Phil Robb Date: Jun 19, 2017, 11:58 AM To: onap-tsc Hello ONAP TSC: I would like to suggest that we approve prior TSC meeting minutes via email so that we don't have to go through that activity during our precious time together on the TSC weekly call. TSC Members please +1 if you approve of this practice, -1 if you want to only approve meeting minutes in the meeting, or 0 if you abstain from the vote. Thanks, Phil. -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,you may review at https://www.amdocs.com/about/email-disclaimer___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
[onap-tsc] subcommittees
Hi, I suggest moving the wiki pages of all the subcommittees under the TSC page. So people can easily find them. Zhaoxing___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] ONAP TSC Members - Are you Attending the China Face ToFace Next Week?
+1, I will attend Zhaoxing 原始邮件 发件人： ＜pr...@linuxfoundation.org＞ 收件人： ＜onap-tsc@lists.onap.org＞ 日 期 ：2017年06月02日 22:58 主 题 ：[onap-tsc] ONAP TSC Members - Are you Attending the China Face ToFace Next Week? Please +1 or -1 if you are attending or not. Please respond ASAP so that we can know who can help facilitate different aspects of the event. Thanks! Phil.. -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] Common Frameworks - Project Proposal
Hi Liron, I don't see significant benefits by putting a new project on top of other projects after going through the "Common Frameworks" proposal. Instead, there are some potential issues. If some codes/modules are put together into one project, ideally, they should be interrelated. But these projects which are claimed to be put into this proposal are created in different problem domains and no overlap. This will create some management problems, such as How to correctly define the committer for this project? Committers are supposed to have written the seed codes and have the right skills to contribute to the project, and they have access to modify and commit the codes of the project which they are in. Given that the needed skillset and background knowledge are totally different for the individual projects inside this proposal, it's hard to assign access control to committers properly. This project will become too huge to manage, for example, the mailist, gerrit, jira, meeting, etc. will be full of a lot of unrelated discussion and clues, similar to the current TSC maillist, which are flooded by messages coming from different concerns. Thanks, Zhaoxing 原始邮件 发件人： ＜liron.shtraich...@amdocs.com＞ 收件人： ＜onap-tsc@lists.onap.org＞ 日 期 ：2017年06月01日 18:00 主 题 ：[onap-tsc] Common Frameworks - Project Proposal Hello Committee Members, I would like to submit the following project proposal: https://wiki.onap.org/display/DW/Common+Frameworks?src=contextnavpagetreemode This project is a consolidation of several other common projects that were already introduced to this committee Thanx, Liron This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,you may review at https://www.amdocs.com/about/email-disclaimer___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
[onap-tsc] Fw：Re: [onap-discuss] [ONAP EXTERNAL OPEN SOURCECOMMUNITY COORDINATOR] Election Kickoff
Hi Phil, According to the forwarded email, Jamil confirmed that he is running for the SDO coordinator. I am afraid that you missed to including him as candidates for election voting. Zhaoxing 原始邮件 发件人: jamil.cha...@orange.com 收件人:Phil Robb onap-tsc onap-disc...@lists.onap.org 日期: 2017-05-18 21:57:51 主题:Re: [onap-discuss] [onap-tsc] [ONAP EXTERNAL OPEN SOURCECOMMUNITY COORDINATOR] Election Kickoff Hello I would like to confirm my self-nomination for SDO coordinator Regards jamil De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] De la part de jamil.cha...@orange.com Envoyé : jeudi 18 mai 2017 00:46 À : Phil Robb onap-tsc onap-disc...@lists.onap.org Objet : Re: [onap-tsc] [ONAP EXTERNAL OPEN SOURCE COMMUNITY COORDINATOR] Election Kickoff Hello Team I would like to nominate myself for the election of ONAP Open Source and SDO Coordinator. In order to accelerate the adoption of ONAP as an industry standard, a strong collaboration between ONAP project and major SDOs and open source projects is needed. As I am leading cloud computing, NFV and SDN standards and open source activities at Orange, I have a solid experience to serve this role. I have contributed to the creation of OPNFV with an objective to deliver a carrier-grade platform for NFV. I am also involved in the development of ETSI NFV specifications as well as the publication of several standards on cloud computing, SDN and Big Data in ITU-T and ISO/IEC. Here after my short bio: · Since 2012, Coordinating Orange delegates active in different standard organisations like ETSI NFV, IETF, ITU-T SG 13, DMTF, ISO /IEC, 3GPP. · Since 2016, OPNFV Board director representing Service Provider Silver members. · Since 2015, OpenDaylight Advisory group member representing Orange. · 2012-2016 Chairman of the cloud computing Working Party, in ITU-T Study Group 13 ‘Future Networks, SDN and Cloud’ · 2012-2014 Co-convener of the joint Collaborative Team (CT) between ITU-T SG13 and ISO IEC/ JTC1 SC38 on Cloud Computing Overview & Vocabulary (ISO 17788) and Cloud Computing architecture (ISO 17789). https://www.linkedin.com/in/jamil-chawki-a57a5a3/ https://twitter.com/jchawki Regards Jamil Chawki Orange Labs De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] De la part de Phil Robb Envoyé : vendredi 12 mai 2017 03:56 À : onap-tsc onap-disc...@lists.onap.org Objet : [onap-tsc] [ONAP EXTERNAL OPEN SOURCE COMMUNITY COORDINATOR] Election Kickoff Hello ONAP Community Members: Please consider this email as the kickoff of the ONAP External Open Source Community Coordinator Election process. A description of the role can be found on the ONAP Technical Community Coordinator's page here: https://wiki.onap.org/display/DW/Technical+Community+Coordinators Please recall, as stated in section 5.2.2.2 of the ONAP TSC Charter, any member of the technical community is eligible to run for this position. It is not exclusively reserved for TSC Members. However, only TSC members are eligible to vote when choosing among the potential candidates. This position serves at the pleasure of the TSC and TSC Chairperson. There are two phases to the election process. The first is the Nomination Phase where community members may nominate themselves for the position of "ONAP External Open Source Community Coordinator". Once the Nomination Phase has concluded, we will enter the Election Phase, where all ONAP TSC Members are invited and encouraged to vote on the candidates whom have been nominated. Timing: § Nominations open May 11th, 2017. § Nominations close May 17th at 9:00pm Pacific Time § Voting begins May 18th, 2017 § Voting Ends May 24th, 2017 at 9:00pm Pacific Time If you wish to nominate yourself for the position of "ONAP External Open Source Community Coordinator", please respond-all to this email with your picture (headshot), biography, and statement of interest on why you would wish to hold the position. I wlll post this information to the wiki prior to the start of the election so that everyone in the technical community is able to become familiar with the candidates. If you have any questions, please do not hesitate to contact me. Best, Phil. -- Phil Robb Executive Director, OpenDaylight Project VP Operations - Networking & Orchestration, The Linux Foundation (O) 970-229-5949 (M) 970-420-4292 Skype: Phil.Robb _
Re: [onap-tsc] Release Naming
Hi Mazin, I prefer #1. Because the city name can be recognized by broader community members and outside users of ONAP compared to the other options. ZTE City would like to change Tianjin to Chengdu, giant panda hometown. Thanks, Zhaoxing 原始邮件 发件人： ＜ma...@research.att.com＞ 收件人： ＜onap-tsc@lists.onap.org＞ 日 期 ：2017年05月17日 01:24 主 题 ：[onap-tsc] Release Naming Team, I have two proposals for release naming. One from Rueben Klein and the other from Gildas Lanilis. The first is famous cities belonging to platinum members, and the other is famous conductors in the domain of orchestrating:-) Both follow the alphabet style. Please review and share comments before our TSC meeting on Thursday. Thanks Mazin Option 1 Platinum Member Country Major Locations IBM US Armonk China Mobile/Telecom China Beijing Amdocs US Chesterfield AT&T US Dallas Nokia Finland Espoo VMWare US (IL) Herzliya Intel US Irvine Ericsson Sweden Kista Tech Mahindra India Mumbai Gigaspaces US New York Bell Canada Canada Ottawa Orange France Paris Cisco US San Jose Huawei China Shenzhen ZTE China Tianjin Option 2 Famous Conductors: As ONAP plays in the domain of orchestrating, we could use the name of famous conductors. Continuous Naming: Amadeus, Beethoven, Chopin, Debussy, Enescu, Foote, Gershwin, Handel, Ilyich, Johannes Non-Continuous naming: Amadeus, Beethoven, Chopin, Debussy, Gershwin, Liszt, Puccini, Ravel, Schubert, Tchaikovsky, Vivaldi, Wagner___ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal at OASIS TOSCA WG
Hi Nati and all, I think we should focus on the requirement from opensource which is to include standard workflow DSL such as BPMN or BPEL as an alternative workflow approach for TOSCA service lifecycle management process modelling, rather than how to figure out a "sophisticated" mechanism to address all the raised questions of this approach, or we can't accomplish it in a predictable timeline. The solution might not look to be perfect right now but work very well in the orchestration implementation. Even in TOSCA Specification, there're still some parts needed to be improved, but we embrace the ideas and allow them to evolve in the right direction. Please let me share a famous Chinese saying here "不积硅步,无以至千里", or in western, we say "Rome was not built in a day". Thanks, Zhaoxing 原始邮件 发件人： ＜na...@gigaspaces.com＞ 收件人： ＜mich...@gigaspaces.com＞赵化冰10201488 抄送人： ＜onap-disc...@lists.onap.org＞ ＜onap-tsc@lists.onap.org＞ 日 期 ：2017年05月11日 21:42 主 题 ：Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN supportproposal at OASIS TOSCA WG "The proposal has been discussed in the OASIS TOSCA for a couple of weeks and most of the members agreed on it except the strong pushback from Michael of Gigaspaces." Huabing et al I wanted to ask that we will keep the discussion on a professional and not a personal level. First i want to clarify what were discussing here right now is not a question of declarative vs impressive workflow as it is being coined for some reason. What were really discussing is whether we use TOSCA as a configuration input or as a model that represent a live system and allow continues interaction with system through the model e.g. Model Driven. So the discussion is wether ONAP orchestration should be truly model driven or not and not whether we should support declarative vs imperative workflow and whether that workflow should be written in BPMN or some other language. There is also no real argument on whether you can or can't use BPMN as a workflow engine. Intact if things done right we should't even care about it. I think that we all agreed that an implementor can choose to run the workflow in what ever language or format he wishes and that should become a "black-box" from the Orchestrator perspective. To allow this kind of flexibility i.e. allow the implementor to choose the workflow language that fits best to his needs we need to define a clear interface on how the execution get called and also how the state of the model get effected once that execution is completed. That's what Michael is basically trying to say repetitively but unfortunately he's comment are being ignored. Both Michael myself are more than happy to work with you or anyone else on the proposal for defining those interfaces assuming that we agree with the goal and scope toward a true Model Driven orchestration. Speaking of a community process. I would appreciate if you could respond to the questions that was raised here an on the OASIS discussion about the proposal in order that we could have a constructive dialogue and move forward. Here is a summary of some of those questions that were left un answered: 1. What's in your proposal should be the effect on the model after the execution is completed? (I assume that right now this is considered out of scope in the current proposal right?) 2. Your making assumption on what works for Telco vs Simple use cases. (This goes with the declarative vs imperative for some reason even though i'm not sure how the two are even related). Can you share on what basis are you making those assumptions? 3. If we agree to leave that the implementation of the workflow should be treated as a blackbox why do we need a specific specification proposal for BPMN ? Let's start with that. As i mentioned we would be more than happy to work with you on those areas and put more clarity behind those items. Nati S. On Wed, May 10, 2017 at 9:03 AM Michael Brenner ＜mich...@gigaspaces.com＞ wrote: Huabing, I recognize the need in ONAP to support delegation in TOSCA to external workflow engines. I have said this repeatedly, and still am miss-interpreted. This has nothing to do with backward compatibility to TOSCA 1.0, it only has to do with supporting "facts on the ground/existing implementations". We should get this agreed once for all, and it became obvious in ONAP's Friday modeling discussion. It also became clear that some of these "facts-on-the-ground" use TOSCA in a limited way. This is OK, and I have no issue with that. I can support in TOSCA TC to find the right mechanism to delegate externally, but only if we do it in a way that is complete: that means we need to not only specify how to "get out of TOSCA" but also has to include how to "get back to TOSCA", and "what is the TOSCA orchestrator supposed to do after it delegates externally". I suggest we work jointly to resolve thes
