Page History

Agenda:

The agenda will be:

1. 1. Discussion of the presentation regarding CSAR structure supported for R1
   2. Discussion on the sequence design in SDC
   3. by SDC.
   4. discussion regarding the SDC support for workflow files.
   5. general Q&A

discussion points:

1. SDC supported input CSAR structure which is supported for R1.

   1. 3 Directories: /TOSCA-Metadata, /Artifacts, /Definitions

   2. SDC development team to check if the import CSAR structure can be the same as the output CSAR structure (nested directories inside /Artifacts)

   3. SDC is not supporting images in R1
   4. SDC is doing basic package validation and would fail incorrect package structure/content
   5. VNFSDK team asks about SDC TOSCA validation code
2. SDC presented the number of options for VNF sequencing. 
   1. Using the relationships between the nodes - The following example (https://www.semanticscholar.org/paper/Combining-Declarative-and-Imperative-Cloud-Applica-Breitenb%C3%BCcher-Binz/61332d7f1763d56e298ce59855aed921a61d1f87)
      Shows how the relationships in the model translated to the instantiation sequencing:
      Image Removed
   2. Using the workflow - suggesting to check with SO and VF-C how this is done today
3. Aug-29 Modelling call will have a slot to discuss the leftovers about CSAR package format
4. SDC suggested having a 3-hours call with VF-C team to manually craft one of VoLTE VNFs and the discuss SDC output 
5. VF-C needs to discuss with VoLTE use case team the E2E flow how the design-time output gets to VF-C. Possible options (additional options might exist):
   
   1. Option 1: 
      1. VF-C implements DMaaP API to register on service and resource notification
      2. VF-C implements SDC catalog API to get service and VNFs
   2. Option 2:
      1. VF-C implements only SDC catalog API and based on SO call gets the service/VNFs from SDC

Action items (to be completed by Tuesday Aug-29):

1. Can the SDC support nested artifacts in imported CSAR?  (owner Tal H.)
2. can the CSAR structure be aligned according to the request to have the service template yaml and mf in the root level (owner Meopeng)
3. Provide VNFSDK team with information and code location about the current SDC CSAR validations (owner Tal H.)
4. VF-C team to provide the list of artifacts that would be included in the onboarded VNF and used by VF-C (owner Meoperg)
5. SDC team to make sure WiKi page is updated with the latest CSAR structure documentation (owner Michael L.)
6. SDC development team to response VF-C questions about TOSCA parser (owner Michael L.)

SDC Supported Import CSAR Structure in R1:

Image Removed

root

/Artifacts - includes all artifacts.

No images
No nesting directories

/Definitions – includes all TOSCA yaml files

Need to include SDC global definition file(s).

MainServiceTemplate.yaml 
MainServiceTemplate.mf 

Metting recording:

meeting Chat:

1. provided documentation regarding the CSAR structure used in SDC: Csar Structure

2. SDC requested that CSARS according to the defined structure be provided for testing.
3. a concern was raised regarding the commitment of the Tosca vendors to support the requested structure.
4. from a discussion, it looks like Nokia did not yet approve the requirement.
5. Tal from Amdocs agreed to provide an example to the expected CSAR so that the other CSAR will be aligned accordingly.
6. based on this example the MF file can be created for the rest of the CSARS.
7. SDC provide information regarding the support that can be achieved for workflows in R1.
   1. SDC suggested a definition of a new artifact type for the workflows.
   2. the artifact type coupled with the CSAR will allow SDC to ingest the workflows from the vendor CSAR into SDC in case the workflows are coming from the vendor.
   3. SDC provides a set of rest API's to upload the workflows to VF instances and to the service, the update will be done using the defined type for the workflows.
   4. all uploaded workflows will be distributed as part of the service CSAR.
   5. SDC suggested review rest API's exposed in order to provide an alternative t e workflow using the parser.
   6. workflow design team clarified that for R1 they will not be creating an API integration with SDC and the workflow attachment process will be manual.
8. SDC continued the discussion regarding the integration with VFC, vfc provided a solution where on orchestration  information regarding the service is passed to VFC by so and using that information the CSAR is retrieved from SDC.
9. sdc provided a review of the issues identified by parcing the SDC CSAR using the open stack parser,
   with the inpout provided by ZTE the issues were categerized into errors and warnings, the warnings will recive a liser priorety the errors will be reviewed and the solution will be discussed:
   1. JSON type show in the csar is not an issue for volte since it will only apper in the heat based usecases.
   2. requirement default is true but no value is assigned, this is under review.
   3. scalar unit type support under review

Action items:

•   Tal Halfon will provide an example of the CSAR expected by SDC with an emphasis on the MF file structure.
  

  View file
  name vCSCF.csar height 150

  
  
•  maopeng zhang will provide the A description of the orcastration flow in order to provide a better butter understanding of the flow and the SDC role in it.
•  maopeng zhang will provide input on the acknowlegment by the vendors providing the VNF for the VOLTE use case to aligne with the SDC requirments.
•  Michael Lando will provide a sugestion to solve the isuess identifed in the CSAR.
•  HuabingZhao will review the SDC API and provide input if any information is missing to support the workflow artifact upload.

Metting recording:

meeting Chat:00:38:55 maopeng: TOSCA-Meta-Version: 1.0 CSAR-Version: 1.0 Created-By: Winery 0.1.37-SNAPSHOT Entry-Definitions: Definitions/openons__vIMS_NS.yaml
00:40:16 maopeng: TOSCA-Meta-File-Version: 1.0 CSAR-Version: 1.1 Created-By: Carlos Santana Entry-Definitions: Definitions/service-33d1f589Dfbc492e8e9b-template.yml
00:45:21 DENG Hui: will VFC get same package format from SDC?
00:46:05 DENG Hui: one change in artificats, two directory: deployment
00:49:33 Nagesha (Nokia): what does helloworld.yml contain ?
00:52:56 DENG Hui: will CSAR package be used for heat vnf as well?
00:54:57 maopeng: In R1, can the VNF package incloude other directiories besides the three mentioned?
00:55:00 David Shadmi: There are some discussion about using it for vCPE. however it would not include HEAT.
00:55:25 David Shadmi: additional directories would be discarded.
00:56:14 David Shadmi: the comment about "additional directories would be discarded" is a response to @maopeng
01:00:15 maopeng: understand, but it is too limited for the VNF vendors. If it can support additional dirctories, it will be more helpful.
01:03:41 DENG Hui: maopeng, could it create other folder under artifact, not in the root directory?
01:04:31 maopeng: it has said it does not support the nesting directories in the artifacts
01:05:18 halfont: David said that we will check it tomaroow and give an answer about it
01:06:10 Nagesha (Nokia): Is this CSAR format for VNF package and also for service package (which user creates service using SDC gui) ?
01:15:08 DENG Hui: mainservice template.mf is duplicate of tosca.meta for SDC
01:16:01 Bharath Thiruveedula-Verizon: can we quickly discuss about the VNF sequencing after this topic, we raised about VNF sequencing in mailing list https://lists.onap.org/pipermail/onap-discuss/2017-August/003803.htm
01:17:41 Nagesha (Nokia): is "MainServiceTemplate" hardcoded name or it can be anything abc.yaml ?
01:17:52 DENG Hui: copy both files from definitions to root
01:18:02 DENG Hui: can u do it ?
01:20:17 DENG Hui: tosca.meta will still configure root direcotry?
01:20:24 maopeng: Entry-Definitions: ./MainserviceTemplate.yaml
01:21:40 DENG Hui: clear
01:22:15 DENG Hui: just copy, don't change content
01:23:54 Victor Gao: does the mainservicetemplate is hardcode?
01:24:13 Victor Gao: the name of ya m l
01:27:52 Nagesha (Nokia): in format the services are distributed ?