Hi guys,
It seems people do want to place to group architecture discussion, but have different opinions on what to cover, how to conduct and what would be the output. My take from open source community is that whoever contributes speaks louder and the TSC committee or its sub-committees should be a place to serve those who contribute to address practical cross-project issues, rather than limiting their innovation or new ways of doing things. In view of that, what are the practical issues we expect to be addressed from architectural activities in the TSC level? In my personal opinion, especially in the initial phase, it is without doubt that important for (1) a small group to quickly develop a high level merger architecture proposal and (2) then hand it over for individual projects to work on the implementation for targeted use cases and (3) later host the discussion if cross-project coordination is needed as separate call on demand whenever issues are brought up. Therefore, I suppose for (1) we do need at least a temporary small group for release 1. But if there is no limitation of participation, there would be actually no practical meaning in set up a sub-committee in the first place. It is just another thread of TSC discussion in nature. And for (2) and (3), I believe they are expected to be revisited and iterated for each subsequent releases and should be open to all, operated on demand in parallel or as part of the regular TSC activities. Right now, we believe we are actually already in between of (1) and (2). For the planned deliverables, I suppose the documentation of the overall architecture of a given release should be deliverable from the documentation project. While the maintenance of the micro-architecture of a given module or the APIs should be self-maintained by individual projects, and kept consistent with the running code, via Swagger Framework, etc. Thanks and Regards, Lingli From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill Sent: 2017年5月17日 4:24 To: Kanagaraj Manickam <kanagaraj.manic...@huawei.com>; Bob Monkman <bob.monk...@arm.com>; Christopher Donley (Chris) <christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee Hi, My view is that architecture alignment is needed and in particular during this formative phase. I think that during this phase, the architecture output will be listened to irrespective of the organizational approach we have. I would like, however, that the projects have freedom within the bounds of the direction as well, and can indeed challenge the architecture – which I am hoping will make a stronger solution over time but attracting innovative people to try and propose new approaches. What I would not like to see is that we cannot try innovative ideas due to “not being decided in the architecture”. For this reason I like the balance that Chris provides with a committee approach. Just my 5c. Best Regards, Steve From: Kanagaraj Manickam [mailto:kanagaraj.manic...@huawei.com] Sent: 16 May 2017 15:14 To: Stephen Terrill <stephen.terr...@ericsson.com <mailto:stephen.terr...@ericsson.com> >; 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: Re: [onap-tsc] Proposal: Architecture Subcommittee Hi Steve, That is the point, project perspective brings more of authorative in nature, to support different projects align as directed by arch. committee. And I tried to suggest the project repo here, helps to store the artifacts, which are approved the project’s committers. Also it keeps track of architecture evolution and API versions across different releases and milestones. Your thoughts. 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! *************************************************************************************** From: Stephen Terrill [mailto:stephen.terr...@ericsson.com] Sent: Monday, May 15, 2017 2:40 AM To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc Subject: RE: Re: [onap-tsc] Proposal: Architecture Subcommittee Hi All, @Chris, thanks for the proposal, I think it’s a good approach. I appreciate very much that its proposed to be open to all. I am responding to this email as it both brings up a few interesting aspects and proposes an alternative approach, which is to have a project for the architecture. I would like to address the proposal for a project based approach. For the complexity we have facing us going forward, we do need alignment in the architecture, however we also benefit from the projects being as autonomous as possible. It’s a balance. I feel that the committee approach, as proposed, can balance between providing guidance and holding things together while allowing at the same time the projects to own the APIs and have innovation in their own architecture, whereas I feel that an architecture project approach would take the balance towards being less advisory in nature and more authorative in nature, which in the long run could be limiting. I think it would be good that the architecture committee could recommend which projects own which interfaces/APIS, and when required, provide guidance on the capabilities of the interface (not how, the project is best position to produce that). One way to express these capabilities is in capturing the e2e informational call flows for the decided use cases. This email contains another proposal, which may actually have being a motivation for a project to have a repo for the artifacts (e.g. UML, or other). There is a point behind this, however I wonder whether we could address this in another way? BR, Steve 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: 12 May 2017 01:55 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.
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
