[OASIS Issue Tracker] (TOSCA-219) Workflow/Plan generation and components state dependency

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/TOSCA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59549#comment-59549 ] 

Luc Boutier commented on TOSCA-219:
-----------------------------------

Not sure that the proposal is correct but I think the issue still exists. I don't think that lifecycle dependencies between component is the responsibility of the orchestrator only as it may have impacts on scripts and archives people can build.

For example if we take the 2015-05-06-TOSCA-Use Case Diagrams.pptx on slide 12 for use-case WebServer-DBMS-1:  WordPress - MySQL

If you implement that for a ubuntu compute for example using apt-get to install both WebServer / Wordpress and MySQL you will have 2 create scripts
create-wordpress.sh and create-mysql.sh (to make it simple and not detail all potential nodes). In many situations you expect that you could run these 2 create operation in parallel because that's faster to process. But unfortunately apt is not able to process 2 requests concurrently!!! So it will crash and my implementation will fail.
In the opposite if I implement things using "manual" downloads from http then I will not have concurrency issues and I want the TOSCA orchestrator to be able to run things in parallel.

In order for people that implements the scripts to understand what they can do and what things exactly implies on orchestrators.

See below 2 use-cases that I have in mind,

Use-case 1:

2 software components using apt-get during create phase and hosted on the same compute node, no dependency between them.

Does the orchestrator may run create phases in parallel
Does the orchestrator runs things in sequential

apt-get does not supports concurrency and may fail if started in parallel.

How do I prevent issues ?
Adding a dependency between components ? => what impact on lifecycle ?

Use-case 2:

Let’s take the deployment of a MapR recommended installation in TOSCA. See picture:

http://doc.mapr.com/download/attachments/26982442/5node_m3.png?version=2&modificationDate=1427512193055&api=v2


In order to match this deployment I need to have 5 compute nodes. Let’s consider only the Zookeeper deployment and consider other Software Components as OtherSC (let’s don’t consider the relationships and dependencies between them for now).

I need 3 Zookeeper nodes and OtherSC depends on Zookeeper. In an ideal world I consider Zookeeper as Up when I reach a quorum (let’s say 2 nodes up on the 3).

What I would like to do is to connect all Zookeeper Node Templates together so they can register other nodes IPs.
The relationship I want to build is bidirectional and we need all Zookeeper nodes connected together.
I plan tu use a pre-configure-source in the relationship to get all IPs
What I think is quite ideal is to perform no specific synchronisation based on state but wait for the IPs attributes
Run create in parallel
as soon as all IPs are available I can launch the pre-configure-source in the zookeeper nodes
run configure
run start

When quorate is reached (or all nodes are started) I should consider my Zookeeper node as available and I can start my other components. (DependsOn meaning do not start as long as the target node is not available it may be started actually).

1/ Can we rely on get_property/attributes to consider that we should wait as long as an attribute is not available => gives a lot of flexibility to users.
2/ Should we also provide a way for user to expect component to reach a state before calling a script on a dependent/connected component ?

If 1 but not 2 then what does DependsOn means vs ConnectTo ?


> Workflow/Plan generation and components state dependency
> --------------------------------------------------------
>
>                 Key: TOSCA-219
>                 URL: https://issues.oasis-open.org/browse/TOSCA-219
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Bug
>          Components: Profile-YAML
>            Reporter: Luc Boutier
>
> Currently we have a quite good workflow for node management and relationships scripts injection. However one notion that is really important is a bit missing, what is the state of my target (or what I expect as target state) before some of my workflow is invoked.
> Right now the only operation that is triggered with a known state is add_target where both nodes are already started an this may not be enough.
> Basically in order to process most of HostedOn scenario (install a software on a compute, install a database on a RDBMS) I expect the target node to be started before the source node workflow is triggered.
> In some HostedOn scenarios I may want to launch create operation when the target node is created or configured (copy a war in the tomcat directory before it starts).
> There is the same problems related to connectsto relationship: for some components we may need to make sure that the target node is started before we call the pre_configure_source or post_configure_source (for example to configure a database in a configuration file before the application is started).



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)