+1. The architecture subcommittee should NOT put gating requirements on any projects. Projects should be responsible for their own release plans and resources. I want to stress that my proposal is for an advisory committee, not a controlling committee. Specifically, the architecture subcommittee doesn’t have the power to make decisions or vote. By Charter, that is solely the purview of the TSC. If decisions need to be made, such issues will be brought to the TSC.
The architecture subcommittee is advisory by nature, and not authoritative. It may provide advice to projects and to the TSC, such as by providing a forum to help resolve architectural questions that may arise. The subcommittee should help to set a target functional architecture for the community (but not mandate it). That target may move over time, and it may take projects more than one release to catch up to it. Scoping would be the responsibility of each project. I also think there should be room for innovation. If a team has a good idea that would change the functional architecture, we may want to consider it. I believe having a consensus target and a defined forum helps facilitate those conversations. In the draft release plan, there is a checkpoint between functionality freeze and API freeze for an architecture check. I think that would be a good spot for the architecture subcommittee to schedule a walk-through with each project to discuss the handoffs between each component to identify any gaps so that teams have time to respond prior to API freeze. The subcommittee should be asking questions, not dictating answers. Chris From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] Sent: Friday, May 12, 2017 6:42 AM To: aayush.bhatna...@ril.com Cc: GOLDNER, ALLA; Kanagaraj Manickam; bob.monk...@arm.com; Christopher Donley (Chris); onap-tsc@lists.onap.org Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee Don’t get my comment wrong I am in full support of an architecture subcommittee. I am somewhat worried on scope and process though. If the architecture team can put release gating requirements on the project as outlined below (maybe I didn’t understand that correctly …) what is the process to ensure that they are realistic in the next release (enough resources available in the project) and align with the priorities of the volunteers in the projects which do the work. If they don’t they won’t get implemented and we don’t have a release. I thought release features are worked by the projects. It always worries me if you separate the decision process from the resources as without resources even the best decision has no value. Oliver On May 12, 2017, at 2:01 AM, aayush.bhatna...@ril.com<mailto:aayush.bhatna...@ril.com> wrote: +1 for the subcommittee formation. Additional proposal on the deliverables of the architectural subcommittee - - Create the deployment architecture for ONAP especially for multi-DC VNF orchestration. This aspect is important as ONAP components such as the DCAE follow an edge-lake architecture which becomes relevant only when we visualize a multi-site deployment. - Define the architectural principles of disaster recovery (DR) orchestrated by the MSO and Policy Engine for VNFs. Regards Aayush ________________________________ From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> on behalf of Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>> Sent: Friday, May 12, 2017 10:29 AM To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee Hi, According to the Charter, It is expected that subcommittee membership shall be open to all ONAP Contributors; however, subcommittees may impose restrictions such as the number of participants from a single company. While the desire may be to keep its size and scope limited, each subcommittee shall be open to the ONAP membership. In particular, a Platinum member has the right to appoint its TSC representative or a designate to such a subcommittee. Also, all elected TSC members are eligible to join a subcommittee Thus, I guess, this one will follow the same rules. Best regards, Alla Goldner Open Network Division Amdocs Technology <image001.png> From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam Sent: Friday, May 12, 2017 2:55 AM To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; Christopher Donley (Chris) <christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>; onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>> Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee IMHO, its really an important and critical team for onap community to ride in right path and to maintain the integrity of onap projects as a whole. so would like to suggest an idea to systematically handle it as below - should we consider architecture as a project, which will have ptl, committers and any contributors and importantly git repository. so that we formalize the approval process of the given change in onap architecture. - instead of ppt format, should we use uml and store it in XML in git repository for architecture diagram and use some tool automate the creation of architecture diagram from XML - as part of it, could we bring approval process for nbi and sbi of each component of architecture as well. - in addition, should integration project automate the validation of nbi and sbi of the project deliverable whether it meets the approved ones by architecture committee, who already had committed the nbi and sbi in architecture git repository in the appropriate form like one of yang, swagger, etc. interoperability will be taken care by this way. this end2end process will govern the integrity of onap architecture as a whole. and i am not sure, but it could bring opportunities to non tsc member as a committer in architecture project☺ for bringing his(er) expertise to onap. your thoughts. --- Kanagaraj M From:Bob Monkman To:Christopher Donley (Chris),onap-tsc, Date:2017-05-12 00:44:28 Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee +1 😊 Robert (Bob) Monkman Networking Software Strategy & Ecosystem Programs ARM 150 Rose Orchard Way San Jose, Ca 95134 M: +1.510.676.5490 Skype: robert.monkman From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com] Sent: Thursday, May 11, 2017 12:03 PM To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: RE: Proposal: Architecture Subcommittee Bob, I propose that it’s open to anyone, regardless of membership level (if any). Thanks, Chris From: Bob Monkman [mailto:bob.monk...@arm.com] Sent: Thursday, May 11, 2017 11:32 AM To: Christopher Donley (Chris); onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: RE: Proposal: Architecture Subcommittee Chris, TSC, Can Silver members put forth a representative to contribute to the architecture subcommittee, or will this be only available to TSC members or representatives from member companies of a certain level? This would seem to be to be a very important step for ONAP, btw. Very helpful to the success of this project. Regards, Bob Robert (Bob) Monkman Networking Software Strategy & Ecosystem Programs ARM 150 Rose Orchard Way San Jose, Ca 95134 M: +1.510.676.5490 Skype: robert.monkman From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris) Sent: Thursday, May 11, 2017 10:53 AM To: onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: [onap-tsc] Proposal: Architecture Subcommittee Dear TSC, I'd like to propose the formation of an architecture subcommittee to develop and maintain a functional architecture for ONAP. Please see the details below. Chris • TSC subcommittee name: Architecture Subcommittee (ARC) • TSC subcommittee purpose: The architecture subcommittee is responsible for developing and maintaining a functional ONAP architecture. This functional architecture helps inform relationships and interaction between functional modules, which may include high level information flows between the modules supporting the use case(s) driving each release. It also helps the community with project proposals by clarifying the new project relationship with existing components. The architecture subcommittee will not make decisions regarding internal functioning of projects. The architecture subcommittee is advisory by nature, and not authoritative. It may provide advice to projects and to the TSC, such as by providing a forum to help resolve architectural questions that may arise. The architecture subcommittee operates on a rough consensus basis. If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee will refer the matter to the TSC or inform the project that advice cannot be rendered. The architecture subcommittee will consult with Projects to help drive alignment between components and with the functional architecture. • TSC subcommittee expected deliverables: The architecture subcommittee will develop and maintain a functional architecture diagram and any explanatory material. Periodically, or midway through a release, the architecture subcommittee will schedule a walk-through with each project to understand API interactions between components. • TSC subcommittee starting participants: The architecture subcommittee is open to all interested participants, and meetings are open. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=Bkwl95SeTK_WdJ57FYz3AsjA8YUdb5infU91lRi5_DU&s=-ZfzhXCnlMgEculgM8eH1pHOWcCyAz9BQFwLXnNrB3E&e=> "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment." _______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org<mailto: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=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4&m=Bkwl95SeTK_WdJ57FYz3AsjA8YUdb5infU91lRi5_DU&s=50orEl5F6nKuM7TwEegtYBau7CubX5JD_8dp0xbVovc&e=
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
