FW: [tosca-comment] RE: Comment on #TOSCA Simple Profile in YAML v1.3

Dear TOSCA-teers,

FYI, please find the latest âVo threadâ (merged) from TOSCA-comments below, which I share without further comment.

Regards,

Paul

From: tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org> On Behalf Of Tal Liron
Sent: Thursday, February 13, 2020 12:02 PM
To: Tri.Vo-Hoang@t-systems.com
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca-comment@lists.oasis-open.org
Subject: Re: [tosca-comment] RE: Comment on #TOSCA Simple Profile in YAML v1.3

On Thu, Feb 13, 2020 at 6:00 AM <Tri.Vo-Hoang@t-systems.com> wrote:

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.

I think I did not explain myself clearly. I am not suggesting that you do not use TOSCA. I am suggesting that you do not have to use the normative types that are provided in TOSCA (the "simple profile"). Treat them as an example, not as a recommended implementation. Instead, you can do your own reverse engineering and create much better types. As you point out yourself, the existing types have inconsistencies and a lack of clarity about resource interrelationships. So, why use them? Make something better.

From: tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org> On Behalf Of Tri.Vo-Hoang@t-systems.com
Sent: Thursday, February 13, 2020 7:00 AM
To: tliron@redhat.com; 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 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.

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>
Gesendet: Donnerstag, 13. Februar 2020 06:55
An: Chris Lauwers <lauwers@ubicity.com>
Cc: Vo Hoang, Tri <Tri.Vo-Hoang@t-systems.com>; tosca-comment@lists.oasis-open.org
Betreff: Re: [tosca-comment] RE: Comment on #TOSCA Simple Profile in YAML v1.3

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:

Hi Vo,

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?

Thanks,

Chris

From: Tri.Vo-Hoang@t-systems.com <Tri.Vo-Hoang@t-systems.com>
Sent: Friday, February 7, 2020 2:58 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca-comment@lists.oasis-open.org
Subject: AW: Comment on #TOSCA Simple Profile in YAML v1.3

Hi Chris,

Actually the use case is as simple as: âA user wants to spawn one Compute node in a given Network with one fixed private IP addressâ.

From my point of view, TOSCA should describe a desired topology of a user as it is. It would be unexpected for the users to see their booted compute node having two NICs (eth0 and eth1) but in the topology they describe only one Port.

> In the current Compute node type, we donât explicitly model that interface using a Port, but rather just track the allocated IP address.

But in Section 8.4.3.2 (Use case: Data Traffic network), the figure shows a scenario whereby users can define eth0 on the VM for their data network explicitly.

Also, it is important to model and control the lifecycle of all interfaces explicitly. This makes sure that a compute node reaches a desired state (i.e., has fixed IP addresses). Otherwise, a restart of a compute node results in a different IP address, and opened to security threats (e.g., causes disruption of availability or the automatic configuration of IP addresses enables an attacker to divert traffic or impair communication).

> Perhaps you can share your use case (or we can discuss when you join the TC).

This process will take a whileâ I hope soon.

Best,

Tri

Von: Chris Lauwers <lauwers@ubicity.com>
Gesendet: Freitag, 7. Februar 2020 04:48
An: Vo Hoang, Tri <Tri.Vo-Hoang@t-systems.com>; tosca-comment@lists.oasis-open.org
Cc: Chris Lauwers <lauwers@ubicity.com>
Betreff: RE: Comment on #TOSCA Simple Profile in YAML v1.3

Hi Vo,

Thanks for explaining your use case. From your explanation, I assume you want the Port B for your Compute A to correspond to eth0 (i.e. the first network interface on the VM). Presumably, this network interface will be used to connect to a âmanagement networkâ that can also be used by the orchestrator to communicate with the Compute node. In the current Compute node type, we donât explicitly model that interface using a Port, but rather just track the allocated IP address. It seems you have a use case in mind for why you want to explicitly model the management address of a Compute host using a Port. Perhaps you can share your use case (or we can discuss when you join the TC).

Thanks again for your input.

Chris

From: Tri.Vo-Hoang@t-systems.com <Tri.Vo-Hoang@t-systems.com>
Sent: Wednesday, February 5, 2020 4:29 PM
To: Chris Lauwers <lauwers@ubicity.com>; tosca-comment@lists.oasis-open.org
Subject: AW: Comment on #TOSCA Simple Profile in YAML v1.3

Dear Chris Lauwers,

thank you for answering my comment.

To be more precise, it is possible to add a Port to a ârunningâ Compute. However, the following scenario does not work well: A topology with one Compute A with one Port B (e.g., Port B has an IP address 10.0.0.2). If Port B âdepends onâ Compute A as in the current spec, regarding Section 7.2.2.2.1, the orchestration engine will âcreateâ Compute A first, waiting for Compute A to âstartedâ, then âcreateâ Port B.

To create Compute A, the orchestration engine requires either a network-uuid, or a port-uuid [1].

a. In the first case, the server is create inside the given network and OpenStack implicitly creates a Port with a random IP in this network (e.g., 10.0.0.3) for the Compute. Obviously, this is not what we expected. Alternatively, the orchestration engine can specify the IP 10.0.0.2 of Port B when creating the server. In such a case, the step âcreateâ Compute A covers the step âcreateâ of Port B.

b. In the latter case, the orchestration engine does not have the port-uuid of Port B yet.

If the relationship is reverse (i.e., Compute A âdepends onâ Port B), then it is what OpenStack users normally do: create a Port, then create a Compute with the Port [2].

I am fine with this.
Yes, I would like to join the TOSCA TC.

[1] https://docs.openstack.org/api-ref/compute/#create-server

[2] https://computingforgeeks.com/create-openstack-instance-with-a-fixed-ip-address/

Best regards,

Vo

Von: Chris Lauwers <lauwers@ubicity.com>
Gesendet: Mittwoch, 5. Februar 2020 18:26
An: Vo Hoang, Tri <Tri.Vo-Hoang@t-systems.com>; tosca-comment@lists.oasis-open.org
Betreff: RE: Comment on #TOSCA Simple Profile in YAML v1.3

Hi Vo,

Weâre excited to hear about your efforts to build a TOSCA-based orchestration engine. With respect to your questions:

The current Port model is closely aligned with Openstack, where it is possible to create a Compute first, and then add a Port to that Compute later. Does that scenario not work for you?
AttachesTo is explicitly designed for Storage. While the name may suggest a more âgeneral purposeâ mission, its focus is on Storage.

These are good comments, and we encourage T-Systems to consider joining the TOSCA TC. It would allow you to participate in the technical discussion where these types of design alternatives are discussed.

Best regards,

Chris Lauwers

From: tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org> On Behalf Of Tri.Vo-Hoang@t-systems.com
Sent: Monday, February 3, 2020 2:58 PM
To: tosca-comment@lists.oasis-open.org
Subject: [tosca-comment] Comment on #TOSCA Simple Profile in YAML v1.3

Dear members of the TOSCA TC,

We are trying to follow the profile v1.3 precisely to implement a TOSCA orchestration engine for our public cloud provider. Currently, we have the following comments:

The tosca.nodes.network.Port has the âBindsToâ relationship (derived from the âDependsOnâ relationship) with the tosca.nodes.Compute. The DependsOn relationship indicates that the Compute node must be created and started before the creation of the network Port. However, in case the Compute node has only one network port, it cannot be created without the Port. Otherwise, the compute node has no IP address and cannot e.g., setup cloud-init. Do you think the direction of the relationship should be reverse?

The tosca.relationships.AttachesTo represents an attachment relationship between two nodes. Therefore, we think the tosca.relationships.network.BindsTo should be derived from the tosca.relationships.AttachesTo (instead of deriving from the tosca.relationships.DependsOn). In such a case, we say, we start a Compute node and bind it to / attach it to an available network Port.

Kind Regards,

Vo

T-SYSTEMS INTERNATIONAL GMBH
Digital & Security | Public Cloud Managed Services

Open Telekom Cloud Delivery â Senior Public Cloud Architect

Hoang Tri Vo, PhD
Holzhauser Str. 4-8, 13509 Berlin (Germany)
+49 151 64922645 (Mobile)
E-Mail: Tri.Vo-Hoang@t-systems.com

Publications: https://dblp.org/pers/hd/v/Vo:Tri_Hoang

Linkedin: https://www.linkedin.com/in/tri-hoang-vo-395819aa/

Legal notice: please see www.t-systems.com/compulsory-statement

Big changes start small â conserve resources by not printing every e-mail.

tosca message