RE: Comment on #TOSCA Simple Profile in YAML v1.3

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tri,

 

I’m curious how you resolved your question below. Did you introduce a custom Port node type that reverses the relationship?

 

As you may know, starting with TOSCA v2.0, we will maintain the Simple Profile type definitions as Open Source contributions on https://github.com/oasis-open/tosca-community-contributions/tree/master/profiles

 

We currently have v1.x definitions in the repository, but will create v2.0 definitions soon. We’d love your participation in this effort.

 

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.

 

1. 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].

1. 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.
2. 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].

2. I am fine with this.
3. 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:

 

1. 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?
2. 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:

 

1. 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?

 

2. 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.