[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Groups - TOSCA Architectures and Language impact uploaded
Hi Tal, Yes, we should continue to discuss this. In my opinion, there is a huge difference between âfind me something that already existsâ vs. âcreate me something newâ. The âcreate something newâ may have cost implications, in which case the service
designer will want to control the creation explicitly. I donât believe that an orchestrator should ever go and create something that a service designer has not explicitly asked for.
Letâs continue to discuss during our upcoming language meetings. Thanks Chris From: Tal Liron <tliron@redhat.com> On Tue, Nov 17, 2020 at 1:51 PM Chris Lauwers <lauwers@ubicity.com> wrote:
I think these are often useful but not absolutely required and indeed there can be twists.
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]