Without âinstance model inventoryâ and âTOSCA service catalogâ, the functionality that can be provided by these functional blocks is severely limited:
I think these are often useful but not absolutely required and indeed there can be twists.
- Without an âinstance model inventoryâ, the ârequirement fulfillmentâ function can only consider/select node instances that are created from the same service template as the template
that contains the dangling requirement (which renders the requirement fulfillment feature almost useless)
- Without a âTOSCA service catalogâ, the substitution function can only consider service templates that are packaged in the same CSAR as the service template that contains the abstract
node(s) that require substitution.
Of course, as you know I disagree with the "dangling requirement" feature, and in my view these two features are essentially identical for the orchestrator in that they allow for a node to be "provided" from somewhere else. The difference in #2 is a TOSCA grammatical feature, allowing a TOSCA service template to explicitly "provide" a node.
My point is that how exactly the orchestrator "provides" is beyond the scope of TOSCA. It could be an inventory, but it doesn't have to be. The orchestrator could simply look for existing resources in the cloud, whether they were created via TOSCA or not, thus the cloud itself becomes the inventory. And of course an orchestrator could also provision such implementations itself on-demand. As for catalogs, it does seem that if a service template does substitution then of course the orchestrator would have to know of it and thus it must be "somewhere". But, again, it doesn't have to be in a catalog. For example, a bunch of CSARs can be provided at once to the orchestrator, to be used just at the moment of the day 1 instantiation, and they do not necessarily have to live in a catalog.
My one concern here is that inventories and catalogs involve state and and state management, but there is a lot of room for orchestration that is as stateless and lightweight as possible. I still think the minimal architecture is functionally sufficient for TOSCA orchestration.
My second concern is not to scare off potential consumers of TOSCA, who might look at a complex architectural diagram and worry about the amount of effort they would need to put in in order to make use of TOSCA.