A shallow hierarchy of TOSCA node types. Everything is just a resource.


A resource may contain components, which are also resources:


The TOSCA way to implement such a recurrent containment relationship is as following:





  • No labels

8 Comments

  1. Andrei Kojukhov

    This diagram relates to a discussion about naming conventions. One approach is defined in TOSCA NFV profile in YAML.

    1. Anatoly Katzman

      Right. I will fix the names later

  2. shitao li

    what is the meaning of the arrow in the above figure?

    1. Anatoly Katzman

      It is inheritance

  3. Chesla Wechsler

    When you say ResourceInstanceTemplate, do you really mean the instance of a resource (i.e., we've finished orchestration and there is now an instance of this resource)? I think not and, if not, should this name be changed to prevent confusion?

    1. Anatoly Katzman

      Here I mean a design-time "instance" of a resource within a "container" topology. 

      And yes, this naming collision between the design-time instances and run-time instances is a problem, very confusing. I have tried to introduce the term "occurrence" instead of the design-time "instance", but this proposal didn't fly. So now I am at the 2nd attempt, this time with the term "template". Hope this will get better acceptance among those who writes TOSCA..

  4. Priya TG

    Hello Anatoly, Can you let me know why we are not using or extending from the normative types defined in TOSCA NFV Profile Specifications?

    1. Anatoly Katzman

      The motivation is to reuse the existing NFV definitions as much as possible, however not all of them accurately fit into the model. In these cases we are just going ahead with a replacement. The models will converge eventually, of course.