Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers
Hi, Oliver, Please see comments inline. Regards, Helen Chen From: "SPATSCHECK, OLIVER" <spat...@research.att.com> Date: Wednesday, May 10, 2017 at 7:01 PM To: "zhao.huab...@zte.com.cn" <zhao.huab...@zte.com.cn> Cc: Helen Chen 00725961 <helen.c...@huawei.com>, "onap-tsc@lists.onap.org" <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers I guess where I was getting confused is who is managing the micro services themselves. E.g. DCAE uses micro services. The micro services in DCAE are managed by the DCAE controller in terms of life cycle management (turning up the micro services, monitoring the health of the micro service, turning down the micro service). In this case the DCAE controller also partially handles service discovery. My understanding was that the OOM will handle those tasks going forward in a unified way. [HELEN] I think it is “Microservice Framework” been positioned to eventually provide a “unified way” to handle that, including doing the refactorying for DCAE in the future. OOM manages it through “Microservice Framework” (whatever it will be called). So let me see if I am getting this straight now. Is the following statement true? If I have a micro service within ONAP the OOM manages: - turn up - faults - turn down - auto scaling [HELEN] My understanding is that OOM doesn’t manage on micro service level. In OOM’s diagram about “Service & config registry” is not micro service. (Maybe I am wrong, let them clarify it). the micro service framework manages - service registration - service discovery - service load balaning Do both teams agree to this separation? If that is the case I agree that they are separate tasks and that the term micro service framework is very misleading as I would have thought a framework also handled turn up, faults, turn down and auto scaling. Maybe we should go back to micro service bus then. Those projects are obviously still closely related though. E.g. if you turn up a micro service (as the OOM would do) you have to let the micro service bus know about it (e.g. register it). [HELEN] Agree. They are very close to each other. Helen, I am not sure I understand the difference between a component of ONAP and a tool. For the OOM to manage the above life cycle events of micro services and other components in ONAP it has to be running at the same operational level as any other ONAP component does. So it’s not just a “script” you run once. It’s a component. It just doesn’t directly interact with VNFs but that doesn’t make it less important. [HELEN] What I mean is that a component of ONAP is without it, ONAP is not complete, while tool is that without it, ONAP is still fully function. (They all equally important). It may run at the same operational level or may not. OOM manages ONAP through ONAP’s API, or installs a proxy/agent, or using Kubernetes to manage the container where those ONAP components run inside if they use container (some of them use VM). My 2 cents. ☺ Thx Oliver On May 10, 2017, at 8:55 PM, zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn> wrote: What Helen said is correct. During the project proposal discussion in the last week, people suggest use "Microservice Framework " instead of "Microservice Bus", that might be the reason of this confusion. "Microservice Framework" or "Microservice Bus" provides a platform to enable service registration/discovery, service request routing, service load balancing for the services. From the project description of OOM(ONAP Operations Manager), OOM intends to Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). So the scopes of these two project obviously have no any overlapping. Thanks, Huabing Original Mail Sender: ＜helen.c...@huawei.com<mailto:helen.c...@huawei.com>＞; To: ＜spat...@research.att.com<mailto:spat...@research.att.com>＞; ＜david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>＞; CC: ＜onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>＞; Date: 2017/05/11 07:21 Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers As I understand correctly: First of all, from its functionality, Microservices Framework focus on helping project which uses microservices to easier manage their services, including register/discover, etc. through its services bus; it is the content, and where it will be installed, is out of its scope. And OOM focus on where it will be installed, (from theory, it could be packed in a VM or a container), but OOM chose docker. Secondly from its distribution, Microservices Framework is part of ONAP itself; while OOM will be distributed as tools for ONAP, just as some tools which will be distributed from Integration project. Rega
Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers
I guess where I was getting confused is who is managing the micro services themselves. E.g. DCAE uses micro services. The micro services in DCAE are managed by the DCAE controller in terms of life cycle management (turning up the micro services, monitoring the health of the micro service, turning down the micro service). In this case the DCAE controller also partially handles service discovery. My understanding was that the OOM will handle those tasks going forward in a unified way. So let me see if I am getting this straight now. Is the following statement true? If I have a micro service within ONAP the OOM manages: - turn up - faults - turn down - auto scaling the micro service framework manages - service registration - service discovery - service load balaning Do both teams agree to this separation? If that is the case I agree that they are separate tasks and that the term micro service framework is very misleading as I would have thought a framework also handled turn up, faults, turn down and auto scaling. Maybe we should go back to micro service bus then. Those projects are obviously still closely related though. E.g. if you turn up a micro service (as the OOM would do) you have to let the micro service bus know about it (e.g. register it). Helen, I am not sure I understand the difference between a component of ONAP and a tool. For the OOM to manage the above life cycle events of micro services and other components in ONAP it has to be running at the same operational level as any other ONAP component does. So it’s not just a “script” you run once. It’s a component. It just doesn’t directly interact with VNFs but that doesn’t make it less important. Thx Oliver On May 10, 2017, at 8:55 PM, zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn> wrote: What Helen said is correct. During the project proposal discussion in the last week, people suggest use "Microservice Framework " instead of "Microservice Bus", that might be the reason of this confusion. "Microservice Framework" or "Microservice Bus" provides a platform to enable service registration/discovery, service request routing, service load balancing for the services. From the project description of OOM(ONAP Operations Manager), OOM intends to Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). So the scopes of these two project obviously have no any overlapping. Thanks, Huabing Original Mail Sender: ＜helen.c...@huawei.com<mailto:helen.c...@huawei.com>＞; To: ＜spat...@research.att.com<mailto:spat...@research.att.com>＞; ＜david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>＞; CC: ＜onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>＞; Date: 2017/05/11 07:21 Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers As I understand correctly: First of all, from its functionality, Microservices Framework focus on helping project which uses microservices to easier manage their services, including register/discover, etc. through its services bus; it is the content, and where it will be installed, is out of its scope. And OOM focus on where it will be installed, (from theory, it could be packed in a VM or a container), but OOM chose docker. Secondly from its distribution, Microservices Framework is part of ONAP itself; while OOM will be distributed as tools for ONAP, just as some tools which will be distributed from Integration project. Regards, Helen Chen On 5/10/17, 1:23 PM, "SPATSCHECK, OLIVER (OLIVER)" ＜spat...@research.att.com<mailto:spat...@research.att.com>＞ wrote: One more question. I am wondering what the relationship of the Microservice Framework (https://wiki.onap.org/display/DW/Microservices+Framework) and below is. Below says: ＞＞ The OOM addresses the current lack of consistent platform-wide method in managing software components, their health, resiliency and other lifecycle management functions. the Microservice Framework proposal says: ＞＞Standardize ONAP platform Microservies concepts & principles and provide key framework it seems the Microservice Framework is a subset of the the Operations Manager and container proposal in scope. Am I interpreting this correctly? Thx Oliver ＞ On May 10, 2017, at 3:35 PM EDT, Sauvageau, David ＜david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>＞ wrote: ＞ ＞ Oliver – I can move it there. Was not aware thanks ＞ ＞ On 2017-05-10, 3:30 PM, "SPATSCHECK, OLIVER (OLIVER)" ＜spat...@research.att.com<mailto:spat...@research.att.com>＞ wrote: ＞ ＞ ＞I would assume so otherwise we would have duplication. ＞ ＞On an editorial note I thought we were supposed to move the proposal links above the project proposal draft line h
Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers
What Helen said is correct. During the project proposal discussion in the last week, people suggest use "Microservice Framework " instead of "Microservice Bus", that might be the reason of this confusion. "Microservice Framework" or "Microservice Bus" provides a platform to enable service registration/discovery, service request routing, service load balancing for the services. From the project description of OOM(ONAP Operations Manager), OOM intends to Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). So the scopes of these two project obviously have no any overlapping. Thanks, Huabing Original Mail Sender: ＜helen.c...@huawei.com＞ To: ＜spat...@research.att.com＞ ＜david.sauvag...@bell.ca＞ CC: ＜onap-tsc@lists.onap.org＞ Date: 2017/05/11 07:21 Subject: Re: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP onContainers As I understand correctly: First of all, from its functionality, Microservices Framework focus on helping project which uses microservices to easier manage their services, including register/discover, etc. through its services bus it is the content, and where it will be installed, is out of its scope. And OOM focus on where it will be installed, (from theory, it could be packed in a VM or a container), but OOM chose docker. Secondly from its distribution, Microservices Framework is part of ONAP itself while OOM will be distributed as tools for ONAP, just as some tools which will be distributed from Integration project. Regards, Helen Chen On 5/10/17, 1:23 PM, "SPATSCHECK, OLIVER (OLIVER)" ＜spat...@research.att.com＞ wrote: One more question. I am wondering what the relationship of the Microservice Framework (https://wiki.onap.org/display/DW/Microservices+Framework) and below is. Below says: ＞＞ The OOM addresses the current lack of consistent platform-wide method in managing software components, their health, resiliency and other lifecycle management functions. the Microservice Framework proposal says: ＞＞Standardize ONAP platform Microservies concepts & principles and provide key framework it seems the Microservice Framework is a subset of the the Operations Manager and container proposal in scope. Am I interpreting this correctly? Thx Oliver ＞ On May 10, 2017, at 3:35 PM EDT, Sauvageau, David ＜david.sauvag...@bell.ca＞ wrote: ＞ ＞ Oliver – I can move it there. Was not aware thanks ＞ ＞ On 2017-05-10, 3:30 PM, "SPATSCHECK, OLIVER (OLIVER)" ＜spat...@research.att.com＞ wrote: ＞ ＞ ＞I would assume so otherwise we would have duplication. ＞ ＞On an editorial note I thought we were supposed to move the proposal links above the project proposal draft line here: ＞ ＞ https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Proposing-2BA-2BProject=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=KRq5UXk7n766idl0S3NdoJnXVXF7vWo4f17PKdHET6o= ＞ ＞when they are ready for the TSC review period. ＞ ＞Thx ＞ ＞Oliver ＞ ＞＞ On May 10, 2017, at 3:11 PM EDT, Yunxia Chen ＜helen.c...@huawei.com＞ wrote: ＞＞ ＞＞ Hi, David, ＞＞ Could this manager be used for “Distribution” and “Packaging” of ONAP? Please refer to: ＞＞ https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Integration=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=XtcCxrSC2x1iAS_-wkrcO7OCAMRT4JckuzoQHdrNC88= ＞＞ ＞＞ Regards, ＞＞ ＞＞ Helen Chen ＞＞ ＞＞ From: ＜onap-tsc-boun...@lists.onap.org＞ on behalf of "Sauvageau, David" ＜david.sauvag...@bell.ca＞ ＞＞ Date: Wednesday, May 10, 2017 at 11:30 AM ＞＞ To: "onap-tsc@lists.onap.org" ＜onap-tsc@lists.onap.org＞ ＞＞ Subject: [onap-tsc] Project Proposal: ONAP Operations Manager / ONAP on Containers ＞＞ ＞＞ Dear TSC, ＞＞ ＞＞ I would like to formally propose 2 projects to simplify the deployment and the operations of the ONAP platform and components. ＞＞ ＞＞ Project: ONAP Operations Manager (Formerly ONAP controller) - https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_ONAP-2BOperations-2BManager=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI=cWvCFE12-w_VUckpxGTlbzQL9KTHmva1ejCez71IL9c=JKrpL9bPGtCjFYFOQv1RHpooQ1UEvvb5Sqbl3r_-TTY= ＞＞ ＞＞ This proposal introduces the ONAP Platform OOM (ONAP Operations Manager) to efficiently Deploy, Manage, Operate the ONAP platform and its components (e.g. MSO, DCAE, SDC, etc.) and infrastructure (VMs, Containers). The OOM addresses
