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.
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 >
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.
Attachment: workflow.png Description: workflow.png -- This publicly archived list offers a means to provide input to the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe:
tosca-comment-subscribe@lists.oasis-open.org Unsubscribe:
tosca-comment-unsubscribe@lists.oasis-open.org List help:
tosca-comment-help@lists.oasis-open.org List archive:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.oasis-open.org%2Farchives%2Ftosca-comment%2F&data=02%7C01%7C%7C0af43786effa490d0ccd08d7b07c4e2b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637171920258903859&sdata=%2BEwVt0sqhbJVfXGy%2F7xHypcZxCEPTAnImhhYvMbGGt4%3D&reserved=0 Feedback License:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oasis-open.org%2Fwho%2Fipr%2Ffeedback_license.pdf&data=02%7C01%7C%7C0af43786effa490d0ccd08d7b07c4e2b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637171920258913864&sdata=INQOmZ3zu9Apj%2BRINATt%2BTqKwDVJErzcTHV%2FCSVddsk%3D&reserved=0 List Guidelines:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oasis-open.org%2Fmaillists%2Fguidelines.php&data=02%7C01%7C%7C0af43786effa490d0ccd08d7b07c4e2b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637171920258913864&sdata=FUoEZqusemW7gyfNkbDNhxxyOxk1k4fJnc7Iv70uI9Y%3D&reserved=0 Committee:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Ftosca&data=02%7C01%7C%7C0af43786effa490d0ccd08d7b07c4e2b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637171920258913864&sdata=Kp5QLR2V7tQANJjCnUG7UU%2BAJiqHbY8ldzW8sKc%2FyU0%3D&reserved=0 Join OASIS:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oasis-open.org%2Fjoin%2F&data=02%7C01%7C%7C0af43786effa490d0ccd08d7b07c4e2b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637171920258913864&sdata=6BgnZSXbHv8mnYQMBIkfbUJ9DIgMgPlR56KN86cK170%3D&reserved=0