Self Serve Control Loop
| Project | Requirement | Commitment | Notes |
|---|---|---|---|
| DCAE | Blueprint Generator alignment with SDC team to align on blueprint generation (k8s) | Goal #3 | |
| Policy | Enhance Policy SDC Distribution Application to parse CSAR for DCAE service component policy models. If the model is new, the application will call the Policy Lifecycle API to create a Policy Model for that model. | Goal #8 | |
SDC | Support TOSCA compliant model for DCAE service components | Goal #1 | |
| Support Policy DCAE Service Component Model in TOSCA-Lab | Goal #1 | ||
| Generate K8S ready Cloudify Blueprints. | Complete | Goal #2 | |
| SDC will need to make changes to the blueprint to reference the Policy DCAE service component Model from #1 | Goal #3 | ||
| Support the uploading of the JSON spec for a micro service component and create a TOSCA YAML policy model and default blueprint in the SDC Catalog | Goal #4 | ||
| DCAE Service Components and Blueprints need to be added to the service CSAR | Goal #7 |
Where are goals 5 and 6?
2 Comments
Timo Puha
Vijay Kumaraguruthasan commented in DCAE DDF session that there is now a Java rewrite of ToscaLab called Blueprint generator that will replace the python based Toscalab.
While that makes it easier to include to SDC, I would prefer to maximize the use of TOSCA encoding in service CSAR and all handling of blueprint internals in DCAE. This will make generic TOSCA tools more useful for the CSARs, for example other orchestrators.
Pamela Dragosh
Going off what Ofir Sonsinoalso suggested during today's Control Loop DDF session, for any artifacts that are required to be in the CSAR that are non-TOSCA compliant and generated by any other ONAP or 3rd party tool, then the suggestion is to utilize the SDC Catalog API to add those artifacts. They would then be included into the CSAR.