-
Type:
Task
-
Status: New
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Container, Profile-YAML, Spec - Simple Profile
-
Labels:None
-
Proposal:
I'm attaching a graph diagram representing the set of nodes I could need on my orchestrator.
My Approach is the following:
1) create a VM either on CloudStack or on Azure
2) execute all the IP acquire APi commands, do port mappoing and so on since the orchestrator is outside the Cloud Environment
3) install Docker-engine (or I could have it already there, but this is trivial)
4) create the Docker images with the Apache end MySQL
5) deploy the Containers on the Docker engine based on the image
Data inserted by the end user during the process:
1) wordpress web site name and domain name
2) wordpress admin password
3) MySql account password
In gold the relations that needs properties and information to enable a correct management
In light blue the nodes I do not WANT to create since I expect that the cloud environment does for me
in blue the nodes I WILL NOT create since the deployment of the other nodes will generate also those ones (eth0 is generated by CloudStack and DockerBridge is generated by the Docker rpm package).
The problem is ....
Which is the correct TOSCA definition for this topology?
As you can see there are a number of cases here:
1) There are nodes that are not created by the orchestrator but their existence in the TOSCA definition is needed to allow the orchestrator to read the needed attributes
2) There is more than 1 NIC in the Compute node
3) there is the problem of an Acquired IP form the Cloud
These is the problem that the DB account has to be created with user data and that is not possible to merge this information in the an endpoint.database capability since we need to state that we connect the the DB (the one that own the information on which port it bind to and can get the info of the address of the host is hosted on) so the relation from the wordpress to the mysql needs to have more than one property to state to which Db and using what account it connect to the DB engine (is the merge of 3 entity information here) and information has to be dynamically taken from the instance of the appropriate nodes if we want to empower future lifecycle like "change password",
Relations could be more effectively managed by using the relationship_template (A.8.1) where there should be the information for the edges of the graph since in the node_template we should find just the information on the "nodes" as the name imply. Mixing the two things is another quirk that generate confusion in the orchestrator implementation.