TOSCA

tosca.notes

TOSCA is a way to describe application infrastructure. Designed by comittee called OASIS.

If you want to look at it, start with Eclipse Winery.

Because Winery is a Java app, nobody runs online demo, so you need to run it yourself
(there is probably a fresh recorded demo somewhere, so post a link if you've seen one)

Winery is a UI that allows you to draw diagrams that are then saved as CSAR files.

CSAR files contain TOSCA diagrams in YAML format that defines infrastructure like
Terraform or Kubernetes.

If you need to provision infrastructure described in TOSCA diagram, you need a separate
tool called ... well, no idea how do they call it - an orchestrator? Or perhaps
'toscerator`?

xOpera is one of such tools. It takes TOSCA definitioins, tries to find if it has
Ansible playbooks that can do actions defined in TOSACL YAML on defined nodes, and
executed playbooks.

---[Day 2: Another day, another try]---

TOSCA is a perfect example of engineering by comeettee, that composes of people with
certain state of fixed mindset. Absolutely ignoring the UX revolution, it started as
XML based format in 2014, and after 6 years when it became apparent that XML is hard
to parse, hard to write, hard to read, they released YAML version. Without providing
any tools of reference implementation to convert stuff. I am not putting the blame
on those people - they've got full time jobs, and they have no time and experienc to
reengineer things properly. They also have a short lifespan. As I am. That's why I
write notes - to remind myself of this stuff, how these things work, how did they
waste my time, and how I was mad about wasting my time (which I waste anyway). If
there is a one thing that makes TOSCA great, it is people sponsored by EU grants
that are really responsive and kind. I hope they will be supported in future too.

Topology and Orchestration. This is TO. Cloud Applications. CA. Because there are no
clouds, but only other people computers, the standard uses a lot of hazy cloudy words
so that a self-taught engineer without a Master's degree could not understand a thing.
At the same time the standard is so generic that it in essence just describes how how
to describe a generic graph (as in DAG) with nodes, properties and connections between
them. In XML. Well, in YAML. So what they did, is that they've put Object Oriented
Programming in XML, and the ported it to YAML. So before you could even do anything, you
define your "classes" (**types**), then **templates** for "classes" (C++ anyone?) that
place restrictions on how those types can be used if their objects are created.

So we have **type** and its restrictions. First restriction is **capabilities:** - this
is YAML key that contains the stuff that this **type** will provide if it is created
successfully. "Created" means created for real, somewhere. So far I can't tell what
should happen if the **type** with defined by **node_template** restrictions can't be
created, like when service can not provide space or CPUs needed. The **template** also
contains **requirements:** - this stuff is not about external services, this stuff is
about requirements from other types. Like `WebApp` type can require `Compute` type to be
present.

---[Day 3: Torch walk in the rabbit hole]---

I like solving riddles, finding answers, hacking stuff and coding. Can't say I don't
enjoy the experience so far. No matter how impractical it may seem, there is some beauty
in the amount of work that was made to dig it and decorate with patterns.

TIL: `property` - what you want, `attribute`- what you get.