search

SODALITE-EU / xopera-rest-api

Implementation of the xOpera orchestrator REST API
3 stars 0 forks source link

Extend blueprint API to carry out online CSAR conversion #106

Closed pmundt closed 3 years ago

pmundt commented 3 years ago

In the Vehicle IoT case, we would like to be able to submit a TOSCA YAML payload for deployment, but will be doing this via Dart, and not Python, so are unable to carry out the conversion offline in advance. It would be great if we can extend the xOpera REST API to either expose a blueprint2CSAR conversion endpoint, or to support receiving a TOSCA YAML payload and doing the conversion internally when the blueprint is submitted. @kmlTE has also mentioned a case of wishing to submit additional deployment artefacts via the REST API, but I'll let him elaborate on these more.

kmlTE commented 3 years ago

A CSAR archive contains not only TOSCA files, but also implementation and deployment artifacts (Ansible playbooks, scripts, configs, etc.). Submitting of these should also be supported

dradX commented 3 years ago

@pmundt, @kmlTE Well we already support the standard deployment TOSCA format (CSAR) in the xopera-rest-api - so adding another endpoint to create a CSAR would be creating another nonstandard (internal) JSON or similar format to transfer data to xopera-rest-api which actually does not make sense if there is a really quite simple-to-implement standard TOSCA format for doing this. I suggest implementing this in the calling client, as we did in iac-blueprint-builder using blueprint2CSAR.

The second point is why would you need to create your own yaml and deploy through xopera-rest-api without using other SODALITE tools such as KB, semantic-reasoner, iac-blueprint-builder etc. So maybe describing the specific usecase in more detail would help us understand the real requirements and come to a better decision.