[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [tosca-comment] RE: Comment on #TOSCA Simple Profile in YAML v1.3
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. 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. 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. 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 Best, Tri [1]
https://docs.openstack.org/api-ref/compute/#create-server [2]
https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html [3]
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-static-private-ip-arm-cli Von: Tal Liron <tliron@redhat.com> Vo, As a contrary stance I would like to point out that the order of provisioning (the "workflow") in this case is platform-dependent. For some platforms networking pathways must be configured before a compute node (virtual
machine? container? baremetal machine?) is created, or maybe just before it is booted. In other cases it happens independently at any time, possibly by configuring VLAN on a switch or enabling SD-WAN on a router. In yet other cases it can happen after provisioning,
but would require a configuration and reboot, which can have effects on other components. Orchestration is hard, isn't it? 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. You seem to have a good understanding of what is needed, so why not create
it? TOSCA is an object-oriented language that lets you create your own types to model the cloud domain as you see fit. As part of our collective work towards TOSCA 2.0 we are considering removing the Simple Profile from the specification and indeed from its normative status. My personal opinion is that nobody should build anything on
top of the Simple Profile at this time, as it seems to be heading towards deprecation, and indeed failed to make a positive impact on cloud orchestration. This is my personal evaluation and I will accept that some might disagree. On Wed, Feb 12, 2020 at 11:36 PM Chris Lauwers <lauwers@ubicity.com> wrote:
|
Attachment:
workflow.png
Description: workflow.png
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]