Re: [onap-tsc] Thoughts on next steps.
even know how that worked in practice. E.g. will > those VNFs be available to competing vendors so they can test/develop ONAP > code?" > > > > We have already finished VoLTE testing in Open-O project with vIMS and vEPC > comes from Huawei, ZTE and Ericsson. There was no problem using this > proprietary vNFs for testing in Open-O. We also commit in ONAP community ZTE > will provide our vNF packages with limited license for testing purpose. > > Deploying and managing vendor vNFs brings practical value to ONAP community. > Anyway, target of ONAP project should be deploying and managing more > commercial vNFs. I believe vNFs from companies other than ZTE and Huawei > are also welcome for the VoLTE usecase. > > > > Best Regards, > > Yuan Yue > > > > 袁越 yuanyue > > 资深战略规划师 Senior Strategy Planner > > 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System > Product > > > > > <9ae3e214c17d49ed935d87c674ba3ee2.jpg> > <24242e5637af428891c4db731e7765ad.jpg> > 南京市雨花区软件大道50号中兴通讯3号楼 > 1/F,Building 3, ZTE Nanjing R Center II, No.50, Software Avenue,YuHua > District,Nanjing,P.R.China 210012 > T: +025 88013478 > M: +86 13851446442 > E: yuan....@zte.com.cn > www.zte.com.cn > 原始邮件 > 发件人： ＜spat...@research.att.com＞; > 收件人： ＜onap-tsc@lists.onap.org＞; > 日 期 ：2017年05月17日 03:47 > 主 题 ：[onap-tsc] Thoughts on next steps. > > > > I just went through the proposals and noticed that quite a few of them have > not clearly defined boundaries between them which makes me wonder if they > overlap (see table below). From experience overlapping project definitions > rarely lead to good outcomes (duplicate work gets done and people are very > upset at the end…) so I think we should resolve this before approving the > projects. > > When I built this table I focused on what’s written in the proposals. Now > from discussions I think some of the perceived overlaps might just be a > matter of cleaning up the writing. Others might actually be real. In either > case I think we need to be clear and precise in the project description and > can’t rely on various email exchanges for this. I also don’t claim that my > table is complete. If you want I can put the table on the Wiki so people can > add there perceived or real overlaps. > > I don’t know how you usually resolve those issues but I would think that the > project leads for all projects which might have an overlap define a common > statement which defines there relationship with each other in some level of > detail. Thoughts? > > I also looked at the use cases. Lingli and her team did a great job cleaning > up the VoLTE use case: > > https://wiki.onap.org/pages/viewpage.action?pageId=3246140 > > The flow charts are a great start but we do need to get into more details and > actually show the real API calls as well. I am also not sure I understand how > exactly the legacy Open-O and legacy ECOMP components integrate. I think the > next step here is to walk through this in detail. I don’t think that’s > something that can be done efficiently via email. I would suggest a call on > the topic. That might actually be better then a F2F in June as it allows more > developers to dial in. > > One concern on this particular use case is that only Huawei and ZTE have any > VNFs in it. Personally I don’t think it’s a good start for an open project to > start with proprietary VNFs from mainly one manufacturer with some > contribution from a second. I wouldn’t even know how that worked in > practice. E.g. will those VNFs be available to competing vendors so they can > test/develop ONAP code? > > This brings me to overall use case scope and reality. > > Using Gilda’s release plan (all his fault after all :)) we have to work all > of this out by 6/29 (sounds a lot of time but really isn’t). Development is > only 3 months till RC0. We have 32 projects. That’s 21 projects more then the > seed code of 8+3. If I ignore the toy use case we have two use cases > proposed with the VoLTE one having more details then the other. Coordinating > interfaces one on one for the 32 projects requires 512 meetings. …. I think > if we are trying to achieve all of this in release 1 we are setting > ourselves up for failure. > > If it was up to me I would probably just focus the use cases on instantiation > and one simple control loop. This might seem like very little but considering > the work we need to start the projects, set up the labs, get developers > familiar with the environment, get them lab access etc… which all takes > time. I think that would be realistic for a first
Re: [onap-tsc] Thoughts on next steps.
While it is true that part of the idea behind CCF is the creation of a software framework, part of that framework includes whole components that provide the functionality you mentioned for MSB. We have integrated Consul to handle service registration/discovery, service health monitoring, and service configuration storage. It should be noted that CCF doesn’t provide code for micro-service developers. It is intended for controller developers. It is also not limited to micro-service management; micro-services would be a subset of the features provided in CCF. We don’t currently have a common load balancer or service gateway, so I would be very interested in seeing how MSB handles this. In listing DCAE and OOM as candidates for using CCF, I was not intending to be exclusive. There are a number of other “controller” components that can be built on top of CCF; they just aren’t done that way today. -- Christopher A. Rath Director Inventive Science – Intelligent Systems Research Department Advanced Technologies & Platforms D2 Architecture & Design AT Services, Inc. From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn] Sent: Tuesday, May 16, 2017 11:31 PM To: RATH, CHRISTOPHER A (CHRISTOPHER A) <c...@research.att.com> Cc: SPATSCHECK, OLIVER (OLIVER) <spat...@research.att.com>; onap-tsc@lists.onap.org Subject: Re: [onap-tsc] Thoughts on next steps. "For MSB: I agree this should be part of CCF. It could be used by DCAE and OOM." Huabing： MSB and CCF are different and their scope are not overlapping. From the project description of CCF, it will provide "a common set of reusable code that can be used across multiple controllers", it seems like some kind of "Framework" codes refers to a collection of libraries/classes with the common goal of providing a scaffold on which to build controller. Microservices Bus are from OPEN-O code base which provides key infrastructure functionalities to support Microservice Architecture including service registration/discovery, service gateway, service load balancer. It's a pluggable architecture so it can plugin service provider options like AAF to provide Authentication & Authorization for APIs. Microservices Platform also provides a service portal and service requests logging, tracing and monitoring mechanism, etc. MSB doesn't not provide "Framework" codes for building a Microservice. Besides, If we prefer to provide a common "framework" across ONAP projects to build a Microservice, we could consider some open source Microservice frameworks on the table, which provides underlying libraries to support quickly Microservice development and included the mechanisms to handle cross-cutting concerns such as External Configuration, Logging, Health checks, Metrics etc. Here are some candidates: · Java § Spring Boot § Dropwizard · Python § Nameko § Flask · Go § Gizmo § Micro § Go kit And one more thing, As the Microservice Infrastructure, MSB could be used nearly all the ONAP components(Microservices), not only DCAE and OOM. Thanks and Regards, Huabing Original Mail Sender: ＜c...@research.att.com＞; To: ＜spat...@research.att.com＞; ＜onap-tsc@lists.onap.org＞; Date: 2017/05/17 04:05 Subject: Re: [onap-tsc] Thoughts on next steps. For the areas in which I have contributions to consider, here are some clarifications. First, the Common Controller Framework should have overlap as far as scope with a lot of projects. That is the point of that project, to find overlapping functionality, develop it in a single project, and reuse it among the other components. So I would not be concerned with any overlap between CCF and the other projects dealing with deployment, management, orchestration, etc. That is by design.. For DCAE: we have recognized an overlap with Holmes, which in my view should be a sub-project of DCAE, but it does not appear that sub-projects were proposed this way. DMaaP does not have an overlap with DCAE. DCAE uses DMaaP, as do many other components, but the scopes are completely different. I believe the functionality in DMaaP for data processing does not exist today and it is not clear that it would be part of an open-source release of DMaaP or not anyway. For DMaaP: The CCF overlap is by design. It is our intention to provide a “Data Bus Controller” with responsibility for deploying and managing DMaaP data delivery components where they are needed and when they are needed. That functionality exists in DCAE today, but needs to be pulled out to be generally available across ONAP components. For MSB: I agree this should be part of CCF. It could be used by DCAE and OOM. — Christopher A. Rath Director Inventive Science – Intelligent Services and Platforms Research From: ＜onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>＞ on behalf of "SP
Re: [onap-tsc] Thoughts on next steps.
Hi Oliver and all, My answer to " I wouldn’t even know how that worked in practice. E.g. will those VNFs be available to competing vendors so they can test/develop ONAP code?" We have already finished VoLTE testing in Open-O project with vIMS and vEPC comes from Huawei, ZTE and Ericsson. There was no problem using this proprietary vNFs for testing in Open-O. We also commit in ONAP community ZTE will provide our vNF packages with limited license for testing purpose. Deploying and managing vendor vNFs brings practical value to ONAP community. Anyway, target of ONAP project should be deploying and managing more commercial vNFs. I believe vNFs from companies other than ZTE and Huawei are also welcome for the VoLTE usecase. Best Regards, Yuan Yue 袁越 yuanyue 资深战略规划师 Senior Strategy Planner 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System Product 南京市雨花区软件大道50号中兴通讯3号楼1/F,Building 3, ZTE Nanjing R Center II, No.50, Software Avenue,YuHua District,Nanjing,P.R.China 210012 T: +025 88013478 M: +86 13851446442 E: yuan@zte.com.cn www.zte.com.cn 原始邮件 发件人： ＜spat...@research.att.com＞ 收件人： ＜onap-tsc@lists.onap.org＞ 日 期 ：2017年05月17日 03:47 主 题 ：[onap-tsc] Thoughts on next steps. I just went through the proposals and noticed that quite a few of them have not clearly defined boundaries between them which makes me wonder if they overlap (see table below). From experience overlapping project definitions rarely lead to good outcomes (duplicate work gets done and people are very upset at the end…) so I think we should resolve this before approving the projects. When I built this table I focused on what’s written in the proposals. Now from discussions I think some of the perceived overlaps might just be a matter of cleaning up the writing. Others might actually be real. In either case I think we need to be clear and precise in the project description and can’t rely on various email exchanges for this. I also don’t claim that my table is complete. If you want I can put the table on the Wiki so people can add there perceived or real overlaps. I don’t know how you usually resolve those issues but I would think that the project leads for all projects which might have an overlap define a common statement which defines there relationship with each other in some level of detail. Thoughts? I also looked at the use cases. Lingli and her team did a great job cleaning up the VoLTE use case: https://wiki.onap.org/pages/viewpage.action?pageId=3246140 The flow charts are a great start but we do need to get into more details and actually show the real API calls as well. I am also not sure I understand how exactly the legacy Open-O and legacy ECOMP components integrate. I think the next step here is to walk through this in detail. I don’t think that’s something that can be done efficiently via email. I would suggest a call on the topic. That might actually be better then a F2F in June as it allows more developers to dial in. One concern on this particular use case is that only Huawei and ZTE have any VNFs in it. Personally I don’t think it’s a good start for an open project to start with proprietary VNFs from mainly one manufacturer with some contribution from a second. I wouldn’t even know how that worked in practice. E.g. will those VNFs be available to competing vendors so they can test/develop ONAP code? This brings me to overall use case scope and reality. Using Gilda’s release plan (all his fault after all :)) we have to work all of this out by 6/29 (sounds a lot of time but really isn’t). Development is only 3 months till RC0. We have 32 projects. That’s 21 projects more then the seed code of 8+3. If I ignore the toy use case we have two use cases proposed with the VoLTE one having more details then the other. Coordinating interfaces one on one for the 32 projects requires 512 meetings. …. I think if we are trying to achieve all of this in release 1 we are setting ourselves up for failure. If it was up to me I would probably just focus the use cases on instantiation and one simple control loop. This might seem like very little but considering the work we need to start the projects, set up the labs, get developers familiar with the environment, get them lab access etc… which all takes time. I think that would be realistic for a first release and then we can adjust the second release accordingly. In terms of projects I would be very careful which projects have deliverables in release 1.0. . I don’t think having deliverable in release 1.0 is a gating function of getting a project approved. So the TSC can approve projects that make sense but as said I would discourage some of them to have a contribution to the 1.0 release. Probably just stating the obvious … . Oliver ProjectPotential Scope OverlappAAI APPCCommon Controller… , VF-CAuth
Re: [onap-tsc] Thoughts on next steps.
+1. I like this approach given our focus to get a good release out in Nov. From: <onap-tsc-boun...@lists.onap.org> on behalf of "Haiby, Ranny (Nokia - US/San Jose USA)" <ranny.ha...@nokia.com> Date: Tuesday, May 16, 2017 at 2:10 PM To: "RATH, CHRISTOPHER A (CHRISTOPHER A)" <c...@research.att.com>, "SPATSCHECK, OLIVER (OLIVER)" <spat...@research.att.com>, onap-tsc <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] Thoughts on next steps. @Oliver – I share your concern about having 32 projects and gating the release with deliverables from each one. What I would like to propose is categorization of “core” and “non-core” (or a less derogatory name) projects. Core projects are those that provide the minimum viable product functionality, e.g. A, Modeling, SO, etc. Some projects seem like providing functionality beyond the MVP, such as CLAMP, Holmes, etc. Some projects will fall somewhere in between and we could use our common sense to categorize them. This way the community could focus on reviewing the core projects first, and the release will be gated by deliverables from these projects only. This does not mean that non-core projects will not be approved and worked on in the first release, assuming they are defined, approved and have contributors. There are of course some bad implementation examples of such categorization (OpenStack “Big Tent” anybody?) but I believe we can avoid past mistakes and make this approach work for the benefit of the community. Ranny. From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of RATH, CHRISTOPHER A (CHRISTOPHER A) Sent: Tuesday, May 16, 2017 1:03 PM To: SPATSCHECK, OLIVER (OLIVER) <spat...@research.att.com>; onap-tsc <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] Thoughts on next steps. For the areas in which I have contributions to consider, here are some clarifications. First, the Common Controller Framework should have overlap as far as scope with a lot of projects. That is the point of that project, to find overlapping functionality, develop it in a single project, and reuse it among the other components. So I would not be concerned with any overlap between CCF and the other projects dealing with deployment, management, orchestration, etc. That is by design. For DCAE: we have recognized an overlap with Holmes, which in my view should be a sub-project of DCAE, but it does not appear that sub-projects were proposed this way. DMaaP does not have an overlap with DCAE. DCAE uses DMaaP, as do many other components, but the scopes are completely different. I believe the functionality in DMaaP for data processing does not exist today and it is not clear that it would be part of an open-source release of DMaaP or not anyway. For DMaaP: The CCF overlap is by design. It is our intention to provide a “Data Bus Controller” with responsibility for deploying and managing DMaaP data delivery components where they are needed and when they are needed. That functionality exists in DCAE today, but needs to be pulled out to be generally available across ONAP components. For MSB: I agree this should be part of CCF. It could be used by DCAE and OOM. — Christopher A. Rath Director Inventive Science – Intelligent Services and Platforms Research From: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> on behalf of "SPATSCHECK, OLIVER (OLIVER)" <spat...@research.att.com<mailto:spat...@research.att.com>> Date: Tuesday, May 16, 2017 at 3:47 PM To: onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>> Subject: [onap-tsc] Thoughts on next steps. ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. I just went through the proposals and noticed that quite a few of them have not clearly defined boundaries between them which makes me wonder if they overlap (see table below). From experience overlapping project definitions rarely lead to good outcomes (duplicate work gets done and people are very upset at the end…) so I think we should resolve this before approving the projects. When I built this table I focused on what’s written in the proposals. Now from discussions I think some of the perceived overlaps might just be a matter of cleaning up the writing. Others might actually be real. In either case I think we need to be clear and precise in the project description and can’t rely on various email exchanges for this. I also don’t claim that my table is complete. If you want I can put the table on the Wiki so people can add there perceived or real overlaps. I don’t know how you usually resolve those issues but I would think that the project leads for all projects which might have an overlap define a common statement which defines there relationship wi
Re: [onap-tsc] Thoughts on next steps.
For the areas in which I have contributions to consider, here are some clarifications. First, the Common Controller Framework should have overlap as far as scope with a lot of projects. That is the point of that project, to find overlapping functionality, develop it in a single project, and reuse it among the other components. So I would not be concerned with any overlap between CCF and the other projects dealing with deployment, management, orchestration, etc. That is by design. For DCAE: we have recognized an overlap with Holmes, which in my view should be a sub-project of DCAE, but it does not appear that sub-projects were proposed this way. DMaaP does not have an overlap with DCAE. DCAE uses DMaaP, as do many other components, but the scopes are completely different. I believe the functionality in DMaaP for data processing does not exist today and it is not clear that it would be part of an open-source release of DMaaP or not anyway. For DMaaP: The CCF overlap is by design. It is our intention to provide a “Data Bus Controller” with responsibility for deploying and managing DMaaP data delivery components where they are needed and when they are needed. That functionality exists in DCAE today, but needs to be pulled out to be generally available across ONAP components. For MSB: I agree this should be part of CCF. It could be used by DCAE and OOM. — Christopher A. Rath Director Inventive Science – Intelligent Services and Platforms Research From: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> on behalf of "SPATSCHECK, OLIVER (OLIVER)" <spat...@research.att.com<mailto:spat...@research.att.com>> Date: Tuesday, May 16, 2017 at 3:47 PM To: onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>> Subject: [onap-tsc] Thoughts on next steps. ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. I just went through the proposals and noticed that quite a few of them have not clearly defined boundaries between them which makes me wonder if they overlap (see table below). From experience overlapping project definitions rarely lead to good outcomes (duplicate work gets done and people are very upset at the end…) so I think we should resolve this before approving the projects. When I built this table I focused on what’s written in the proposals. Now from discussions I think some of the perceived overlaps might just be a matter of cleaning up the writing. Others might actually be real. In either case I think we need to be clear and precise in the project description and can’t rely on various email exchanges for this. I also don’t claim that my table is complete. If you want I can put the table on the Wiki so people can add there perceived or real overlaps. I don’t know how you usually resolve those issues but I would think that the project leads for all projects which might have an overlap define a common statement which defines there relationship with each other in some level of detail. Thoughts? I also looked at the use cases. Lingli and her team did a great job cleaning up the VoLTE use case: https://wiki.onap.org/pages/viewpage.action?pageId=3246140<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D3246140=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=mSWkj6dIUv40CROVujozu_XlxP5keHDQDHDFr5pdK8c=1vCiffQlW45jG2jvHk7jIkWuy-A-H0iAdyYLQwP5aeg=6HyvFwD1dgzt-cvOGcGtY7E2YnvsWItIZDMv3gvgcSc=> The flow charts are a great start but we do need to get into more details and actually show the real API calls as well. I am also not sure I understand how exactly the legacy Open-O and legacy ECOMP components integrate. I think the next step here is to walk through this in detail. I don’t think that’s something that can be done efficiently via email. I would suggest a call on the topic. That might actually be better then a F2F in June as it allows more developers to dial in. One concern on this particular use case is that only Huawei and ZTE have any VNFs in it. Personally I don’t think it’s a good start for an open project to start with proprietary VNFs from mainly one manufacturer with some contribution from a second. I wouldn’t even know how that worked in practice. E.g. will those VNFs be available to competing vendors so they can test/develop ONAP code? This brings me to overall use case scope and reality. Using Gilda’s release plan (all his fault after all :)) we have to work all of this out by 6/29 (sounds a lot of time but really isn’t). Development is only 3 months till RC0. We have 32 projects. That’s 21 projects more then the seed code of 8+3. If I ignore the toy use case we have two use cases proposed with the VoLTE one having more details then the other. Coordinating interfaces one on one for the 32 projects requires 512 meetings. …. I think
