Change "topology_template" keyname to "service_template"

[tliron]

Reasons:

1. We have received feedback that the difference between a "topology template" and "service template" is confusing. Let's collapse both into "service template" and remove all mention of "topology template" from the specification, including this keyname.
2. The word "topology template" is unclear and used in an unclear way. A topology is just one aspect of a service, having to do with the relationship between nodes. But in TOSCA policies and groups and even inputs and outputs are also under the topology_template keyname. Indeed, these keynames are aspects of the service, and have nothing to do with topology of the service per se. Renaming the keyname to service_template removes this confusion and more precisely describes the semantics of the keyname.

One argument against this change is that "topology" is up there in the acronym TOSCA. Well, we're not removing the concept or even the word "topology" from the spec. Topology remains a crucial feature in TOSCA, and the word will be brought up whenever we discuss relationships between nodes. We're just not giving it a dedicated keyname. (Well, the most relevant keyname is actually requirements.)

Another argument against change is that is might seem arbitrary and annoying for users to change when upgrading to TOSCA 2.0. Well, actually there is a rather long list of breaking changes in 2.0, and this is not an arbitrary change. Removing the confusion between "service" and "topology" is a meaningful and positive upgrade.

[philippemerle]

Just for information, the first old TOSCA 1.0 specification http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html already contained a notion of Topology Template encoded with TopologyTemplate. The YAML keyname topology_template is just the YAML encoding of this concept. So we should not change something that already works from a long time ago ;-)

[tliron]

It does use that term, but the reason for it seems to be a distinction that existed in TOSCA 1.0 XML but that has not survived. E.g.:

A Service Template describes the structure of a cloud application by means of a Topology Template, and it defines the manageability behavior of the cloud application in the form of Plans.

So "topology template" was used to separate that aspect from "plans" within a "service template". These were distinct sections in the XML. Also note that inputs and outputs were part of the "plan", not the "topology template". (See example in 5.1.) When TOSCA moved to YAML the concept of a "plan" was entirely removed. However, the topology_template keyname remained (as a confusing vestige, in my opinion) and "inputs" and "outputs" were moved into it, despite logically not being related to "topology". I think it's finally time to retire this unused concept.

Even looking back to 1.0 in XML I would say that "topology template" was not the best name for that distinct section.

[pmjordan]

I tend to support this suggestion. If adopted would it affect the the term 'Toplology Model' ?

[tliron]

If by "topology model" you mean "nodes + relationships" then I don't think it should affect the term's meaning or usage. As I said, the term indeed has a meaning for describing an aspect of the service. It's just that 1) the keyname has a different usage (it includes non-topological entities), and 2) by making it a keyname we are implying that it is an "entity" in additional to or separate from the service template, which it isn't.

[pmjordan]

'Topology model' is used a number of times in the 2.0 draft. It is defined in section 2.4 as synonomus with Topolology Template but if your suggestion is accepted that definition would no longer make sense.

[tliron]

Thank you, we should note that and take a look at those uses.

[lauwers]

I tend to support this recommendation as well, since it would allow us to greatly simplify terminology used in the spec:

• What we used to call a "service template" will now be called a TOSCA file.
• A TOSCA file can define a profile (i.e. a collection of types and supporting artifacts), a service template (a template from which running services can be created), or both
• A service template models the service as a graph of node templates and relationships between these nodes. We refer to this model as the service topology
• In addition, a service topology can also define workflows, policies, etc.

[pmjordan]

I agree with most of the point above but the last one 'a service topology can also define workflows, policies, etc.' seems to go back to the problem which this issue is trying to resolve. To me a topology should only include nodes and relationships. It would be acceptable to me for a service template to include workflows, policies, etc.

[lauwers]

Yes, my mistake. I meant to say 'service template', not 'service topology'

[tliron]

This proposal was approved in the TOSCA ad hoc.

[tliron]

This has now been implemented in Puccini.

[lauwers]

This change has been reflected in TOSCA-v2.0-wd05-rev01