RE: Relationships and Order of Node instantiation
> As for target_changed, I don't think ARIA checks the state when executing any > operation. YAML profile spec states the following: "In addition, whenever the node state of its target node changes, the target_changed operation is invoked on it to address this change." I guess ARIA is not compliant here (?). >> Does the ST designer need to specify an implementation artifact for >> such operation? >No, ARIA will just skip operations without implementations. *However*, >it will still change the state accordingly: an operation without an >implementation is considered always to succeed in this case. (And the >opposite is also true: if an implementation artifact fails to run, the >state will not be changed, and indeed the workflow as a whole will >fail.) I think the ST designer needs to specify an implementation for the target_changed operation if the ST designer wants the source node to change/override its state. Now looking back I think it is a bad idea to create an implementation script (associated with target_changed operation) that will change the state of the source node since it is not the way states are handled in TOSCA. Node states are always independent regardless of relationships. Do you agree? In summary, I think it is better if one completely avoid using the normative Configure interface (tosca.interfaces.relationship.Configure) with ARIA or any TOSCA orchestrator since the target node is always instantiated before the source node and operation interleave is not supported for normative deploy/undeploy workflows. Bottom-line, it looks like the Configure interface (tosca.interfaces.relationship.Configure) is only valid when both source and target nodes are instantiated concurrently. Do you agree? -Steve -Original Message- From: Tal Liron [mailto:t...@cloudify.co] Sent: Tuesday, October 03, 2017 1:11 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Relationships and Order of Node instantiation On Tue, Oct 3, 2017 at 11:58 AM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > > It looks like for the normative install workflow, the target node is > always created before the source node regardless of the relationship > (and regardless if it is a normative or custom relationship). > Is this correct? And only a custom workflow can change this "default > direction/ordering", right? > Correct. > For instance, if I stop the target node (target node state goes from > STARTED to CONFIGURED), will ARIA actually perform a target_changed > operation on the source node? > How do you stop just one node? You would a custom workflow for that, and I imagine behavior would have to be very domain-specific if you want the service to remain stable. As for target_changed, I don't think ARIA checks the state when executing any operation. The state is there for you to access and possibly consider when implementation the operation. But ARIA can't know what to do. > If so, what is the information provided in the target_changed? > The operation is defined in the normative interface type as empty, without inputs. That said, ARIA provides a rich interface to the complete context: https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Context > Does the ST designer need to specify an implementation artifact for > such operation? > No, ARIA will just skip operations without implementations. *However*, it will still change the state accordingly: an operation without an implementation is considered always to succeed in this case. (And the oppoiste is also true: if an implementation artifact fails to run, the state will not be changed, and indeed the workflow as a whole will fail.) > In your opinion, should the state of the source node also changed to > CONFIGURED in such case, say for a hosted on relationship? > My opinion doesn't matter too much here, since we are trying to follow the spec as closely as possible... and I recall we had some challenges here, because there was some conflicting information. If you can make a convincing case one way or another, with reference to the spec and its potential errors, then of course we can implement it.
Re: Relationships and Order of Node instantiation
On Tue, Oct 3, 2017 at 11:58 AM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > > It looks like for the normative install workflow, the target node is > always created before the source node regardless of the relationship (and > regardless if it is a normative or custom relationship). > Is this correct? And only a custom workflow can change this "default > direction/ordering", right? > Correct. > For instance, if I stop the target node (target node state goes from > STARTED to CONFIGURED), will ARIA actually perform a target_changed > operation on the source node? > How do you stop just one node? You would a custom workflow for that, and I imagine behavior would have to be very domain-specific if you want the service to remain stable. As for target_changed, I don't think ARIA checks the state when executing any operation. The state is there for you to access and possibly consider when implementation the operation. But ARIA can't know what to do. > If so, what is the information provided in the target_changed? > The operation is defined in the normative interface type as empty, without inputs. That said, ARIA provides a rich interface to the complete context: https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Context > Does the ST designer need to specify an implementation artifact for such > operation? > No, ARIA will just skip operations without implementations. *However*, it will still change the state accordingly: an operation without an implementation is considered always to succeed in this case. (And the oppoiste is also true: if an implementation artifact fails to run, the state will not be changed, and indeed the workflow as a whole will fail.) > In your opinion, should the state of the source node also changed to > CONFIGURED in such case, say for a hosted on relationship? > My opinion doesn't matter too much here, since we are trying to follow the spec as closely as possible... and I recall we had some challenges here, because there was some conflicting information. If you can make a convincing case one way or another, with reference to the spec and its potential errors, then of course we can implement it.
RE: Relationships and Order of Node instantiation
Hi Tal I was trying to clarify how ARIA behaves "by default". It looks like for the normative install workflow, the target node is always created before the source node regardless of the relationship (and regardless if it is a normative or custom relationship). Is this correct? And only a custom workflow can change this "default direction/ordering", right? I have a related question about the Configure interface I know the target_changed operation is supported by ARIA but how far does it go? For instance, if I stop the target node (target node state goes from STARTED to CONFIGURED), will ARIA actually perform a target_changed operation on the source node? If so, what is the information provided in the target_changed? Does the ST designer need to specify an implementation artifact for such operation? In your opinion, should the state of the source node also changed to CONFIGURED in such case, say for a hosted on relationship? Thanks again for your help. Regards Steve B -Original Message- From: Tal Liron [mailto:t...@cloudify.co] Sent: Tuesday, October 03, 2017 12:07 PM To: dev@ariatosca.incubator.apache.org Subject: Re: Relationships and Order of Node instantiation As far as I can tell we do a general reverse topological sort of the graph, so that *all* relationships are considered. So all relationship target nodes would appear before relationship source nodes. I'm not 100% sure this is a great idea. Though all the normative relationships seem to have that order -- attaches to, binds to, hosted on, depends on, etc. -- users might be creating other directions, or indeed having more complex inter-relationships. Of course it's generally impossible to make one size fits all, so ARIA at least lets you create your own custom workflows with whatever ordering you need. But I would guess those are edge cases. Are you encountering an issue or just generally wondering? On Mon, Oct 2, 2017 at 4:55 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > What are the normative relationships where ARIA will instantiate the > target node before the source node (assuming the install workflow for > instance)? > Are they DependsOn and HostedOn? > > Regards > Steve B >
Re: Relationships and Order of Node instantiation
As far as I can tell we do a general reverse topological sort of the graph, so that *all* relationships are considered. So all relationship target nodes would appear before relationship source nodes. I'm not 100% sure this is a great idea. Though all the normative relationships seem to have that order -- attaches to, binds to, hosted on, depends on, etc. -- users might be creating other directions, or indeed having more complex inter-relationships. Of course it's generally impossible to make one size fits all, so ARIA at least lets you create your own custom workflows with whatever ordering you need. But I would guess those are edge cases. Are you encountering an issue or just generally wondering? On Mon, Oct 2, 2017 at 4:55 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > What are the normative relationships where ARIA will instantiate the > target node before the source node (assuming the install workflow for > instance)? > Are they DependsOn and HostedOn? > > Regards > Steve B >
Relationships and Order of Node instantiation
Hi What are the normative relationships where ARIA will instantiate the target node before the source node (assuming the install workflow for instance)? Are they DependsOn and HostedOn? Regards Steve B
