• NOTE: Pam will be on vacation Vijay Venkatesh Kumar will run the meeting.

Discussion items 

ATTENDEES

ONAP Meeting 4 (https://zoom.us/j/824147956) was used for this meeting

NOTES

• Testing status
  • Heat verified last week; OOM based on CLAMP flows blocked by environment issues in integration tenant.
• SDC team question for VES Onboarding artifact usage

               SDC - VES Onboarding artifacts.docx

• Discussion on question from Adam Krysiak on onboarding/analytics events configuration

1. On first diagram ((https://wiki.onap.org/display/DW/MicroServices+Onboarding) there is tool named DCAE_CLI. After reading its API it is able to verify, publish and deploy components on DCAE.     Am I correct that in this process it is used only for validating json with schema?
     [Vijay] – Yes, the dcae_cli tool has following primary usage

• • • Validation of the data_formats  (can be shared across MS
      
• • • Validation of spec file created for each M
      
• • • Deploy/test the container with configuration input to emulate CBS returned data

More information on dcae_cli can be found in RTD - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/components/component-specification/component-specification.html?highlight=component%20spec  
2. Again on first diagram there is tool named TOSCA_Tool. I did small research and I was not able to find component named like this.
    However I've found two components that may be hidden by this name:
    a) modeling/toscaparsers 'nfvparser'    -     responsible for creating TOSCA templates. It suppotts only YAML and CSAR format.  
    b) sdc/dcae-d/tosca-lab  'tosca-lab'    -     Looks like new version of nfvparser. According to README supports YAML. Also has functionality of translating TOSCA to HEAT
    Could you please tell if any of those two is what you meant by TOSCA_Tool? If not can you send me correct project name (perfectly with path where I can find it).
     [Vijay] – I believe sdc/dcae-d/tosca-lab is correct; but this has to be confirmed with SDC team.
3.  I've checked tcaSpec.json that you attached. It looks like it contains all informations to generate both DCAE_blueprint and policy model (that's exacly what we need). Is there any other artifact generated from this spec?
    I'm missing one more piece in here. When policy model is created in Policy? Is SDC DCAE DS creating it?
[Vijay] – There are 4 different model files generated by tosca_lab tools – schema.yaml/template.yaml/translate.yaml/policy.yaml .  The policy.yaml is used by CLAMP/Policy for setting the configuration policy; the other artifacts are used by SDC. Besides these models tosca_lab also has option to generate the blueprints based on the spec.        Currently Clamp has fixed form for configuring TCA. When sending request to create microservice policy it always uses "tca_policy" as microservice.If Policy model is created from schema as it's described then feature "Ease of creating analytic components and on-boarding DCAE micro services" will mainly require making Clamp able to:
    1. find out what kind of microservice policy should be configured.
    2. generate proper form.     3. send microservice policy create request to Policy with proper microservice.
[Vijay] – yes, that’s correct.    

Open questions to be followed with team next week

1) How policy models get distributed to Policy/CLAMP? Does this feature exist currently

2) Confirm with SDC on the Tosca_lab repository

RECORDING

ControlLoop_SC_10172018.mp4