That is a good point. From the OOM perspectivewe believe that deployment mechanism should provide consistency through OOM, and therefore the DCAE controller should probably be replaced by OOM as a consistent re-usable functionality. Generally speaking, we need to provide the equivalent functionality of the DCAE controller across all components (i.e. deploy in the right DCs, auto-scale, etc).
The role of OOM vs DCAE controller should definitely be discussed – but I do not believe each component should have their own “controller function” to perform lifecycle events. From: <[email protected]> on behalf of "[email protected]" <[email protected]> Date: Monday, June 5, 2017 at 2:40 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [onap-discuss] Question on ONAP Operations Manager (OOM) Hi there, After I went through the proposal page of OOM, I feel sort of confused on one point. I hope guys for OOM could help to figure it out. To my understanding, one of the responsibilities of OOM is to manage the lifecycle of the ONAP components, as is mentioned on the page "The users can also deploy ONAP instances, a component, or a change to a software module within a component". But for some components, they have their own controllers to manage the lifecycle of their sub-components. Take DCAE for example, onboarding of microservices is currently being performed by the DCAE controller for analytics applications and data collectors. How does OOM cope with such kind of scenario? Will OOM take over the responsibility of the lifecycle management of sub-projects/sub-modules? Regards, Guangrong
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
