Hi Tri,
When we revisit the Simple Profile types, weâll consider your suggestion to make sure all use cases can be supported. Our focus for the next couple of months is on further specifying the TOSCA language features themselves (rather than focusing
on types).
Thanks,
Chris
From: Tri.Vo-Hoang@t-systems.com <Tri.Vo-Hoang@t-systems.com>
Sent: Tuesday, February 18, 2020 5:46 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca-comment@lists.oasis-open.org
Subject: AW: [tosca-comment] RE: Comment on #TOSCA Simple Profile in YAML v1.3
Dear Chris,
> In that case, the ârandom IP addressâ (presumably allocated using DHCP) can be returned to the orchestrator and stored as an attribute in the Compute node. It is not necessary to model a Port for this scenario.
Again, the scenario is that users want to boot a Compute with one fixed IP address. Therefore, he has to model the Compute and the Port
explicitly.
With the current spec, the Compute will get a random IP address from the default network and one fixed IP address additionally (from the Port), which is unexpected for the users.
The following orchestration engines has implemented that a Compute depends on a Port:
- In
Cloudify, they defined the relationship âserver_connected_to_portâ (derived from ConnectsTo relationship [1, 2]). In this relationship, Server is a source node, Port is a target node. Therefore, the server depends on the port explicitly.
- In
OpenStack HEAT, they defined an intrinsic function âget_resrourceâ to create a nova compute with a port (see example in [3]). The function âget_resrourceâ makes the nova compute depend on the port implicitly.
- In
Terraform, they defined a ânetwork/portâ block inside a âcompute instanceâ resource [4]. As a result, it defines that the compute depends on the network port implicitly.
>
How would your solution handle the case where an additional network connection needs to be created after the Compute node has already been started?
The orchestration engine creates the new Port (i.e., the target node) with the âhost-idâ using the command in [5]. Afterwards, it skips the creation of the Compute (the source node) because it already exists. For Terraform, it also supports
the âbindingâ block inside the ânetworking portâ [6].
[1]
https://docs.cloudify.co/4.5.0/working_with/official_plugins/openstack/#cloudify.openstack.server_connected_to_port
[2]
https://github.com/cloudify-cosmo/cloudify-openstack-plugin/blob/master/plugin.yaml#L1408
[3]
https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#get-resource
[4]
https://www.terraform.io/docs/providers/openstack/r/compute_instance_v2.html#network-port
[5] https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/port.html
[6]
https://www.terraform.io/docs/providers/openstack/r/networking_port_v2.html
Best,
Tri
Hi Tri,
Thanks again for your feedback. More responses in-line.
Dear Liron,
> I would suggest that the Simple Profile is not a good basis for creating a multi-cloud orchestrator because it makes various assumptions that don't really fit any specific cloud, let alone all of them. I personally
recommend that instead of using the Simple Profile that you create your own types (nodes, capabilities, relationships, etc.) that make sense for orchestration solution that you are implementing.
To adapt an application for the cloud environment, prior academic research in the past 10 years have considered the adaptation in two phases: the reverse engineering and the forward engineering phase. In the reverse
engineering phase, TOSCA describes an application in a Platform Independent Model (i.e., an abstract topology with the components and the relationship between the components that works in multiple cloud providers. Then in a forward engineering phase, a Platform
Specific Model can be matched/transformed from the Platform Independent Model. This has been discussed in many academic research. Therefore, I strongly disagree with your above statement.
I personally agree that there is a lot of value in creating a Platform-Independent model. However, the current Simple Profile models were designed primarily for OpenStack, and as a result may not be as âplatform
independentâ as they should be. We could either spend time to improve them (which is what youâre trying to do) or service designers could just create their own to service their specific needs (which is what I believe Tal is suggesting). Both approaches are
valid.
Dear Chris,
> Given that relationships always have directionality, it seems we must make a choice about which use case is more common: create a Compute first, and then bind a Port to it, or create a Port first, and then bind
it to a Compute. Itâs reasonable to ask if both scenarios could be supported. Do you have any suggestions?
Argument 1: The common use case
The creation of the Compute without a Port does not work for OpenStack as in [1], AWS as in [2], and Azure as in [3]. In such as case [1-3], the VM will get a random IP address from the default network.
In that case, the ârandom IP addressâ (presumably allocated using DHCP) can be returned to the orchestrator and stored as an attribute in the Compute node. It is not necessary to model a Port for this scenario.
Argument 2: Missing dependency
In case we have a Software Component hosted on the Compute node. According to the current spec, the SoftwareComponent is created right after the Compute node even when the network Port is not created/ready yet (see
the workflow in the attachment). A workaround is to add an explicit dependency between all SoftwareComponents and the given Port. However, the current specification does not say anywhere that we have to add such dependency.
Youâre correct, but the tosca.nodes.Root type includes a general-purpose âdependencyâ requirement for exactly this reason (i.e. to control the order in which nodes are orchestrated).
Solution:
If the Port âDependsOnâ the Compute, it covers all cases. The definition changes as follows:
tosca.nodes.Compute:
...
requirements:
- local_storage:
...
- binding:
type: tosca.capabilities.network.Bindable
How would your solution handle the case where an additional network connection needs to be created after the Compute node has already been started?
Thanks,
Chris