Using with Eclipse Winery

[abitrolly]

I am trying to figure out how all components of TOSCA ecosystem work together with Ansible included. It would help if the project could provide a zero knowledge entrypoint with Eclipse Winery as an example of configuring, deploying, upgrading and downgrading a simple Python script as a web service on Amazon and GCP.

def hello():
  print("ok")

I am trying to get the understanding what needs to be produced to deploy this script in comparison with traditional way with Ansible, and how the troubleshooting process works from Ansible wrappers.

[anzoman]

Hi @abitrolly and many thanks for opening this.

Eclipse Winery is a powerful TOSCA modelling tool and although this is not our current main focus, our possible future plan also includes exploring other TOSCA modelling tools (e.g., Cloudnet TOSCA toolbox) and documenting their interaction with xOpera.

You say that you're still learning TOSCA. So, apart from TOSCA Simple Profile in YAML v1.3, the Eclipse Winery docs could be a good thing to get started with TOSCA and Winery. And I think that you can get a bunch of good info from xOpera because our xOpera project and opera orchestrator currently uses Ansible to implement the TOSCA standard. You can follow our xOpera documentation or README to get started. More examples can be found in xopera-examples repository and are also explained in our docs. And since you mentioned cloud examples we also have TOSCA templates and CSARs for AWS, Azure and GCP within our examples and docs, so you can see what's the difference between having TOSCA + Ansible and having Ansible solely.

[abitrolly]

Hi @anzoman. I've already explored all the resources you've mentioned, but I still have no idea how a bunch of all these components work together. From the docs I can see that instead of invoking ansible-playbook I can invoke opera, but that's all it shows.

A standard sequence diagram, which include at least infrastructure engineer, Winery, xOpera, app source, CSAR file and Ansible could probably clarify the flow of things for me better than all texts combined.

[anzoman]

You have to be aware that TOSCA is just another layer on top of Ansible that helps to define the application infrastructure and the xOpera orchestrator is able to deploy it.

So, the things should go like that:

1. You can use Winery (= TOSCA modelling tool) to create a new TOSCA application and export a compressed archive called TOSCA CSAR.
2. You can also skip the first step and prepare your TOSCA manually by following our docs and TOSCA docs.
3. The TOSCA YAML template/compressed CSAR contains just the definitions for nodes (e.g., VM, database, website, etc.) and relationships between them (e.g., runs on, connects to, etc.).
4. To be able to deploy the TOSCA nodes you define TOSCA interface operations for every node.
5. The actual work is performed by Ansible so you have to prepare a playbook for every TOSCA node operation.
6. Then you have to link your Ansible playbooks to the TOSCA interface operations (e.g., create, delete, configure, etc.).
7. After that you install xOpera orchestrator (called opera) locally.
8. You deploy your extracted/compressed TOSCA CSAR and the Ansible playbooks behind TOSCA start executing.
9. You observe your deployment results.
10. You can tear down your deployment if you also defined the corresponding delete TOSCA operations and playbooks.
11. And that's it.

I think I don't have a diagram to show you the relation between components, but we will probably create a simple one in the future.

[anzoman]

@abitrolly I would also suggest that you take a look at the following videos that show how xOpera and other tools work in action:

xOpera tools overview: https://www.youtube.com/watch?v=NZLYWB9uxjk xOpera CLI: https://www.youtube.com/watch?v=cb1efi3wnpw&t=1s TPS with CLI: https://youtu.be/28eTwojw5ac TPS with Eclipse Che: https://youtu.be/vCjfZ4Iue0E xOpera SaaS with GUI: https://youtu.be/T4XviKWLc-A xOpera SaaS with Eclipse Che: https://youtu.be/SIiLOe5dSqc GMT (Winery): https://www.youtube.com/watch?v=xEjarBWcdK0 and https://www.youtube.com/watch?v=l0_2E68OaTI

[abitrolly]

Well, product presentation rarely list shortcomings, and they are the main points for evaluating the value behind TOSCA. A lot of presentation materials without clear answers can be a result of the railroad anti-pattern at the design stage. Given that the initiative had just got its 10th birthday https://lists.oasis-open.org/archives/tosca/ and so far the adopters seem to be only academic institutions and projects sponsored by EU grants, I don't intend to invest much time in there. Hence the request.

In any way, thanks for the answer. I would get back to it once I have more time to properly ask follow up questions.

[anzoman]

@abitrolly thanks for your opinion, I agree with you - if the OASIS TOSCA standard would be easy to learn and use, it would definitely be used a lot more and we would also have more tools that support it and more companies that would come closer to it. Although I see TOSCA having a big potential in orchestration and in preventing vendor lock-in, I am using the spec for almost two years now and have seen a lot of issues with the standard itself and had a lot of problems with the adoption and the use of related tools. On the other side you can see that some tools such as Terraform, are gaining popularity because they are easier and faster to adopt. And because of that, we will see what we can do with xOpera orchestrator in order to make the orchestration simpler for the users. However, I hope that TOSCA 2.0 and the next versions will improve the documentation and focus more on simplicity and actual users' needs.

So I think that we can close this issue and if you have any additional questions or ideas feel free to reach out to us again here on GitHub or you can also send an email to xopera@xlab.si.

[abitrolly]

Yes, thanks for answered the question. Let me summarize what I learned.

I can use Eclipse Winery to create TOSCA files that are deployed by xOpera.

• TOSCA is a standard how to describe application infrastructure in a declarative way.
• TOSCA format describes infrastructure the same way as Terraform files or Kubernetes files.
• But TOSCA configuration can be deployed by different tools - xOpera, OpenTOSCA Runtime, etc.

? TOSCA configuration is not like Ansible. TOSCA contains no scripts or playbooks. Is that right? ? If you need custom deployment logic for some TOSCA definition, you need to extend your deployment tools. Yes/no?

• TOSCA CSAR is an archive format that bundles configuration and compiled application artifacts for deployment ? Is the application optional in the archive?

• Deployment tools take CSAR, looks at infrastructure definition, provisions nodes and then deploy application artifacts.

• But TOSCA doesn't describe which command to run to make DB migration or rollback.

• To add custom logic or component, you define new node template in TOSCA format, then code the logic in your deployment tool (implement TOSCA operations that you've defined for your node)

• In xOpera you code the TOSCA operations as Ansible playbooks

[abitrolly]

The largest benefit I see from TOSCA is the usage of visual tools. But for that it needs to be able to reliably parse Kubernetes or Terraform configs to represent in its format for visualization. Terraform has some basic support for drawing config nodes, but it is not as useful or interactive as in Winery.

• https://www.terraform.io/cli/commands/graph
• https://github.com/hashicorp/terraform/issues/20063
• https://github.com/hashicorp/terraform/issues/14511#issuecomment-656256982

For the issues with TOSCA adoption, having a list of the outstanding problems you've run into with TOSCA would certainly be useful both for early adopters and researchers looking for new challenges.