Thank you Srini. I was not able to follow complete conversation and had to
drop in the middle. This summary was really useful to me.

I wanted to ask following query during the meeting, but then had to drop in
the middle. Could you / other members comment on the following ?

The definition of "edge" is still fuzzy and there are several
interpretations. One thing that is common across every definition however,
is the distributed cloud & vastly large deployments ( in the order of
millions ). Based on your earlier session on K8S plugin in MC project, I
was wondering if the K8S Plugin / MC is actually capable of handling
millions of such distributed cloud registrations  ?

When we propose a solution to such vastly distributed problem, have we
considered about simulating such workload to see whether the solutions are
really scalable ?
All the edge demos that I have seen so far are merely 4-5 nodes ( including
core & access edge nodes ) and an orchestrator deploying workloads on the
edge. I mean.. how do we even simulate million nodes and test the
orchestration. I'm wondering whether scalability is taken for granted...?

BR,
Viswa


<http://www.verizon.com>

Viswanath Kumar Skand Priya
Senior Architect
Technology, Architecture & Planning



On Thu, Oct 4, 2018 at 9:15 PM Srini <[email protected]>
wrote:

> Hi,
>
>
>
> There was very good discussion on “Edge domain orchestration in the
> context of MEC”&  “ONAP-Edge workloads”
>
>
>
> Summary of discussion yesterday:
>
>
>
> ONAP-Edge workloads are required to offload some of the ONAP functionality
> to Edges or somewhere near to the edges.
>
>
>
> We discussed few ONAP-Edge workloads
>
>
>
> -        ONAP-Edge analytics (To make analytics closer to the analytics
> data);.
>
> -        ONAP-Edge Policy control (to allow execution of policies upon
> output of analytics applications, mainly drools based policies)
>
>
>
> I think following are also required:
>
>
>
> -        ONAP-Edge Security (to provide security of secrets & private
> keys,  to allow secure communications etc…)
>
> -        ONAP-Edge LCM (To take care of LCM actions locally)
>
> -        ONAP-Edge Fabric Control ( to allow configuration of fabric
> locally)
>
>
>
> We also briefly touched upon following:
>
> -        All ONAP-Edge workloads would be container or VM based
> workloads. But initially, we will be working on container based workloads.
>
> -        Add ONAP-Edge workloads are deployed in edge/regional locations
> in similar way as the VNFs (That is, using Multi-Cloud service plugins).
>
> -        Since ONAP-Edge components are leveraging ONAP projects, we need
> to see what kind of modularization is required.
>
> -        In R4, we will focus on ONAP-Edge Analytics and ONAP-Edge Policy
> Control.
>
>
>
> On MEC:
>
> -        MEC Edge platform is assumed to be workload as far as ONAP is
> concerned.
>
> -        MEC Edge Platform Manager is considered as VNFM.  Need to see
> how external VNFMs are integrated with ONAP when SO based orchestration is
> used.
>
> -        ONAP-Managed and ONAP-unmanaged way of bring MEC applications
> are to be supported.
>
> -        In ONAP-Managed, what kind of changes required to support
> multiple application providers
>
> o   Making ONAP multi-tenant is one item we briefly touched upon.
>
> o   In previous meetings, Manoj volunteered to talk about service
> ordering/onboarding via external API.
>
>
>
> Thanks
>
> Srini
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12840): https://lists.onap.org/g/onap-discuss/message/12840
Mute This Topic: https://lists.onap.org/mt/26793379/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to