All,

There is a current initiative that started in Casablanca that is meant to solve 
this manual preload, among other things: 
https://wiki.onap.org/display/DW/Controller+Design+Studio+Initiative 
<https://wiki.onap.org/display/DW/Controller+Design+Studio+Initiative> Brian 
did touch based on that, it’s the Controller Design Studio initiative.

Goal is to be able to model VNF / VF-Module configuration, both for 
instantiation and post-instantiation.
In Casablanca, CDS is providing support to avoid having to do SDNC preload 
(instantiation use case). 
This is enabled by new SO building-blocks and SDNC GR-API. These new flows are 
fully generic.

Here is the feature set we have in Casablanca, for the vFW use-case:
policy driven naming generation, for vnf and vf-modules (capability)
We have created policies, stored in the policy micro-service, that provide 
recipe to generate a unique name, for the VNF and VF-MODULE.
A naming micro-service as also been created, able to ingest the naming policy,  
along with some params, and generate the name.
open source IPAM Netbox mS  (capability)
Netbox is an IPAM implementation micro-service; it has been added into the 
cli/adaptors/plugin, in order to provide automatic IP assignment based on 
specified IP pool.
For the vFW use cases, we have 3 specific pools, the protected, the 
unprotected, and the onap general purpose.
self serve DG integrated with CDS backend
SDNC self-serve DGs has been created, in order to provide self-serve capability 
both for vnf and vf-module level. Those self-serve DGs are able to leverage in 
capability that has been added to the capability list. Among others, this 
capability list for Casablanca has netbox-ip-assign/unassign and generate-name.
It is possible to add to this list of capability by providing a fairly small 
implementation.
controller blueprint mS
controller blueprint management
controller data dictionary management
The controller blueprint mS allows to design the blueprint for the service. 
This blueprint is TOSCA based, using JSON, not YAML. The blueprint allows to 
define what are the artifacts required for the service, config management, and 
most importantly, data dictionary management.
A data dictionary is a resource to has to be resolved. The data dictionary 
specifies how to resolved the resource.
The controller blueprint mS is a design time process, and we’re targeting to 
have this integrated within SDC for Dublin.
resource accumulator bundle
input
default
generic MD-SAL
generic Database Adapter

The resource accumulator is the runtime component resolving to blueprint for 
the particular service, and is the micro-service responsible for actually 
resolving the resources, based on the model. Casablanca supports resources to 
be resolved from 4 different stream, input, default, MD-SAL or DB.


We have are currently defining Dublin release: 
https://wiki.onap.org/display/DW/CCSDK+Dublin+Controller+Design+Studio+Initiative
 
<https://wiki.onap.org/display/DW/CCSDK+Dublin+Controller+Design+Studio+Initiative>

Please provide feedback and join our weekly meetings, occurring Tuesday and 
Thursday from 11am to 12pm EST: 
https://wiki.onap.org/display/DW/Controller+Design+Studio-Dublin-%5B06%5D-Planning+Calendar
 
<https://wiki.onap.org/display/DW/Controller+Design+Studio-Dublin-[06]-Planning+Calendar>

You can also join Rocket Chat, and join onap_cds channel to ask question:
        http://onap-integration.eastus.cloudapp.azure.com:3000
        Enter the Channel Room: onap_cds

Regards,
Alexis

> On Sep 19, 2018, at 8:53 AM, Viswanath Kumar Skand Priya via Lists.Onap.Org 
> <[email protected]> wrote:
> 
> Hi Brian / Rene / Steven,
> 
> Thanks for the pointers. I understand the need for preload during deployment 
> and that's exactly what VID is trying to achieve . My only comment is about 
> the mandatory flow that exists between SO and SDN-C, inspite of ignoring 
> SDN-C for a deployment.
> 
> Runtime values could be supplied by N ways to VNFs and SDN-C is just one of 
> them. If I don't depend on SDN-C for a network service ( both network & ip 
> address assignment ) and I should be able to just talk to SO and VIM without 
> the need to have additional flows. If SDN-C preload is unchecked, then why SO 
> should talk to SDN-C ?
> 
> BR,
> Viswa
> 
> 
> 
> Viswanath Kumar Skand Priya
> Senior Architect
> Technology, Architecture & Planning
> 
> 
> 
> On Wed, Sep 19, 2018 at 6:10 PM Brian <[email protected]> wrote:
> Not sure. I usually test with the SDNC preload option.
> 
> I suspect its only the .env parameters since the data is added to the 
> parameter line in the stack create when they match .env parameters and 
> ignored if not.
> 
> SO might do other things with that data though.
> 
>
> 
> Brian
> 
>
> 
>
> 
> From: Rajewski Łukasz - Korpo <[email protected]> 
> Sent: Wednesday, September 19, 2018 8:38 AM
> To: FREEMAN, BRIAN D <[email protected]>; [email protected]; Osiński 
> Tomasz 2 - Korpo <[email protected]>
> Subject: RE: Why we need manual SDN-C preloading?
> 
>
> 
> Thanks Brian, it explains a lot.
> 
>
> 
> regarding the option 2, this file contains only values of parameters 
> specified in .env file for heat or there are some other ones required?
> 
>
> 
> Regards,
> 
>
> 
> 
> 
> Łukasz Rajewski, R&D Expert
> Orange Labs Polska, Advancend Networking Systems Agency, Warsaw
> Mobile: +48 519 310 854
> Orange Polska, Obrzeżna 7, 02-691 Warszawa 
> www.orange.pl
> 
>
> 
>
> 
> From: FREEMAN, BRIAN D [mailto:[email protected]] 
> Sent: Wednesday, September 19, 2018 2:31 PM
> To: [email protected]; Osiński Tomasz 2 - Korpo
> Cc: Rajewski Łukasz - Korpo
> Subject: RE: Why we need manual SDN-C preloading?
> 
>
> 
> Tomek,
> 
>
> 
> The issue is how to assign the per instance data that can not part of the 
> model that is used multiple times for instantiation.
> 
>
> 
> There are 3 mechanisms for setting that per instance data.
> 
>
> 
>       • Preload to SDN-C where the instance specific hostnames , network 
> information needed for the VNF to do its function , ssh key etc can be set.
>               • VID users selects the “use sdnc preload” option and SO 
> queries for that data to SDNC at the VF Module instantiation
>       • As a json file uploaded to VID so that the same information is 
> provided to SO
>               • VID users selects the upload json file option instead of “use 
> sdnc preload”
>       • Automated SDN-C assignment where there is a controller design studio 
> template used to do “resource resolution”
>               • VID user doesnt select the use sdnc preload option
>               • As part of the process of VNF design – the network/service 
> designer creates the template for resource resolution and the corresponding 
> policies for thing slike hostnames, query IP Address Management subsystem for 
> assignments and any manually resolved data that came in from VID
>
> 
> It is not a simple problem because the .env file’s that are provided with the 
> VNF heat template’s are not instance specific at model onboarding and each 
> service provider is likely to have unique naming conventions and 
> configuration policies they want to implement.
> 
>
> 
>
> 
> Casablanca will see the initial availability of the Controller Design Studio 
> so you can see more of how the model/policy driven resource resolution will 
> work.
> 
>
> 
> Brian
> 
>
> 
>
> 
> From: [email protected] <[email protected]> On Behalf Of 
> Tomek
> Sent: Wednesday, September 19, 2018 3:27 AM
> To: [email protected]
> Cc: Rajewski Łukasz - Korpo <[email protected]>
> Subject: [onap-discuss] Why we need manual SDN-C preloading?
> 
>
> 
> Hello,
> 
> As in title, why we need manual SDN-C preloading in ONAP? We use and work 
> with ONAP from Amsterdam release. It was surprising for us that there are 
> some additional, manual steps needed to perform orchestration for any single 
> VNF. We have currently ongoing development of Casablanca release and I don’t 
> see the feature requests to automate SDN-C preloading in ONAP. In my opinion 
> it’s just a matter of information exchange between SDC/SO/AAI/SDN-C. 
> 
> Could you explain me why this manual step is still needed for ONAP? Is there 
> any plan to automate it? 
> 
> Regards,
> Tomek
> 
>
> 
> 
> 
> Tomasz Osiński, Main R&D Specialist
> Orange Labs R&D Center
> Tel.: +48 50 130 06 88, 
> Orange Poland, Obrzeżna 7, 02-691 Warsaw 
> www.orange.pl
> 
>
> 
>
> 
> 
> 
> 
> <image001.png><image001.png>


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

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

Reply via email to