RE: [tosca] Proposal for requirement "occurrences"

[Chris Lauwers <lauwers@ubicity.com>]

We really do need to separate grammar discussions from discussions about the core concepts.

 

I do agree with you that TOSCA has always hinted at runtime requirements. Way back years ago when I made my TOSCA tutorial (for 1.0) it was there in the spec as suggestive little wordings, but I could not see how it could be implemented coherently. For example, in TOSCA 1.0 this is how node_filter for node templates was described:

 

The optional filter definition that TOSCA orchestrators would use to select the correct target node. This keyname is only valid if the directive has the value of âselectableâ set.

 

Note that there is no mention of "at runtime" here, and example 2.9.2 is the only place where it is used. And what does "target node" mean here? Target of what? This implies that it relates somehow to the requirements of this node template. Anyway, so little here to build upon.

 

First of all, letâs not use the word âruntimeâ. Runtime in my opinion refers to Day 2, i.e. after the service has been deployed, which is Day 1. Letâs use the word âdeployment timeâ instead.

 

Second, TOSCA hasnât just âhintedâ at deployment-time requirements, in my opinion requirement fulfillment is by definition a deployment-time concept. I donât believe it can be interpreted any other way:

 

• Component designers define Node Types to model their components.
• These node types include requirement definitions that specify capabilities of other components on which the component depends.
• Service designers can âfulfillâ these requirements directly in their service templates by including node templates for these ârequiredâ components, and then fulfilling the requirements by establishing relationships between the components. This is what is meant by âDesign time requirement fulfillmentâ. In this scenario, we no longer need to talk about requirements. We should talk about relationships instead.
• Any requirements that are not fulfilled at design time (by establishing relationships) must be definition be fulfilled at deployment time.

 

In summary:

• Requirements that have been fulfilled at design time result in relationships (and should no longer be referred to as requirements)
• Any remaining requirements must by definition be fulfilled at Deployment time.
• Node filters are used to select the correct target node. The spec clearly states âtarget nodesâ, not âtarget node templatesâ, and selecting target node templates would be impossible anyway since many if not most of the property values in node templates are unknown until deployment time.

 

In the real world, services will *always* depend on things that already exist, be they resources or components of other services that have been deployed previously. Being able to define these dependencies in component models and service templates is in my opinion the most powerful feature of TOSCA. Without this feature, we will never be able to model interactions between TOSCA services and external systems, and TOSCA will forever be limited to supporting toy applications only.

 

Chris