[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: rules for TOSCA intrinsic functions
Hi Priya, I’ll try to re-do Example 17 in the v1.3 specification (where the processors need the IP address of the message bus) since that example needs to be corrected in the specification anyway. I’ll try to send this out over the next couple of
days. Thanks, Chris From: Priya T G <priya.g@netcracker.com> Chris, Apologies for the delay. You are right regarding the use case. Kindly consider an example of load balancer and web server (represented as abstract node templates substituted by topology templates), with the
load balancer using the IP address attribute of web server for this particular case. Let me know your views. Regards, Priya From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers [External Email]
Hi Priya, Thanks for your feedback. I’m hoping to organize these types of comments into a “best practices” chapter at some point. With respect to nr. 4, I don’t believe that use case supports your argument. Since the abstract web server node has a relationship to the abstract database node (presumably created in the top-level service template),
then the substituting web server template will have access to that same relationship (since the substitution mapping syntax will define the ‘equivalency’). This means that the substituting web server template should just call get_attribute across that relationship
directly. There is no need for the attribute value to flow up to the top-level template first and then back down from there.
Thanks, Chris From: Priya T G [mailto:priya.g@netcracker.com]
Chris, Apologies for the delay and for shuffling the order of items in your original email.
When assigning input values to interface operations, we should avoid using get_input functions that retrieve values directly from topology template inputs. It is better to first reflect
topology template inputs into node properties, and then use get_property instead in operation input assignments. That way, we avoid “bypassing” the topology model when calling interface operations. Quite often, topology inputs are used to control a particular operation implementation, for passing some temporary variables that need not be a part of the topology instance model. It would be an overkill to
describe such variables as properties of node type/node template.
A typical example could be a database (with some constituent nodes represented as a topology) connected to a web server (represented as a topology) where the database IP address is required for creation/configuration
of the web server. . Regards, Priya From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers [External Email]
In the context of an editors’ meeting between myself and Calin, we discussed a number of questions related to the use of intrinsic functions. In particular, we debated Example 17 in the v1.3 specification (in Section 2.11.1). This example
shows the following snippet:
We believe the highlighted property assignment (for the mq_service_ip property) has a couple of issues:
What this illustrates is that without some additional “rules”, the use of intrinsic functions could potentially result in incorrect service templates. Calin and I discussed some potential rules. For example:
In addition, there are a couple of areas where we should recommend “best practices”:
This is a very useful construct, since it allows external APIs to drive resource selection by specifying the appropriate input values. However, this raises the question of whether the use of get_property or get_attribute
should also be allowed. I believe it should be clear that get_attribute calls should not be allowed, since that would mean that resource selection is based on run-time information, which is not something I believe we want to do. Get_property calls could make
sense, but get_property calls could access properties from other nodes, including nodes that are referenced using dangling requirements. This means that depending on the order of the requirements, get_property may try to access a node that hasn’t been “selected”
yet. I’ll add this topic to the agenda of one of our future TOSCA Language Ad-Hoc WG meetings. Thanks, Chris The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender
and delete the material from any computer.
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender
and delete the material from any computer. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]