5
5
6
6
The Infrastructure Manager supports the definition of Cloud topologies using `OASIS TOSCA Simple Profile in YAML Version 1.0 <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html >`_.
7
7
8
- The TOSCA support has been developed under de framework of the `INDIGO DataCloud EU project <http://http://www.indigo-datacloud.eu >`_.
8
+ The TOSCA support was developed under the framework of the `INDIGO DataCloud EU project <http://http://www.indigo-datacloud.eu >`_.
9
9
You can see some input examples at
10
- `https://github.com/indigo-dc /tosca-types /tree/master/examples <https://github.com/indigo-dc /tosca-types /tree/master/examples >`_.
10
+ `https://github.com/grycap /tosca/tree/main/templates <https://github.com/grycap /tosca/tree/main/templates >`_.
11
11
12
12
Basic example
13
13
^^^^^^^^^^^^^
@@ -55,7 +55,7 @@ the SSH credentials to access it::
55
55
Setting VMI URI
56
56
^^^^^^^^^^^^^^^^
57
57
58
- As in RADL you can set an specific URI identifying the VMI to use in the VM.
58
+ As in RADL, you can set a specific URI identifying the VMI to use in the VM.
59
59
The URI format is the same used in RADL (:ref: `radl_system `). In this case
60
60
the type must be changed to ``tosca.nodes.indigo.Compute `` (the Compute normative
61
61
type does not support the ``os image `` property), and the image property must
@@ -82,7 +82,7 @@ be added in the ``os`` capability::
82
82
Advanced Compute host properties
83
83
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
84
84
85
- The ``tosca.nodes.indigo.Compute `` custom type add a new set of advanced features to the
85
+ The ``tosca.nodes.indigo.Compute `` custom type adds a new set of advanced features to the
86
86
host properties, enabling the request of GPUs and
87
87
`Intel SGX <https://www.intel.com/content/www/us/en/architecture-and-technology/software-guard-extensions.html >`_ CPU support
88
88
in the compute node::
@@ -109,8 +109,8 @@ Network properties
109
109
Basic properties
110
110
-----------------
111
111
112
- The easiest way to specify network requirements of the Compute node is sing the endpoint capability properties.
113
- For example the following example the compute node requests for a public IP::
112
+ The easiest way to specify network requirements of the Compute node is using the endpoint capability properties.
113
+ For example, the following example the compute node requests for a public IP::
114
114
115
115
...
116
116
simple_node:
@@ -123,15 +123,15 @@ For example the following example the compute node requests for a public IP::
123
123
124
124
Possible values of the ``network_name `` endpoint property:
125
125
126
- * PRIVATE: The Compute node does not requires a public IP. **This is the default behavior if no
126
+ * PRIVATE: The Compute node does not require a public IP. **This is the default behaviour if no
127
127
endpoint capability is defined **.
128
128
* PUBLIC: The Compute node requires a public IP.
129
129
* Network provider ID: As the `provider_id ` network property in RADL
130
130
It defines the name of the network in a specific Cloud provider
131
131
(see :ref: `_radl_network `):
132
132
133
- Furthermore the endpoint capability has a set of additional properties
134
- to set the DNS name of the node or the set of ports to be externally accesible ::
133
+ Furthermore, the endpoint capability has a set of additional properties
134
+ to set the DNS name of the node or the set of ports to be externally accessible ::
135
135
136
136
...
137
137
@@ -151,7 +151,7 @@ to set the DNS name of the node or the set of ports to be externally accesible::
151
151
Advanced properties
152
152
-------------------
153
153
154
- In case that you need a more detailed definition of the networks, you can use the
154
+ In case you need a more detailed definition of the networks, you can use the
155
155
``tosca.nodes.network.Network `` and ``tosca.nodes.network.Port `` TOSCA normative types.
156
156
In this way you can define the set of networks needed in your topology using the ports to
157
157
link the networks with the Compute nodes::
@@ -198,7 +198,7 @@ Custom defined Port type ``tosca.nodes.indigo.network.Port`` has a set of additi
198
198
Software Components
199
199
^^^^^^^^^^^^^^^^^^^
200
200
201
- IM enable to use Ansible playbooks as implementation scripts. Furthermore it enables to specify
201
+ IM enable the use of Ansible playbooks as implementation scripts. Furthermore, it enables to specify
202
202
Ansible roles (``tosca.artifacts.AnsibleGalaxy.role ``) and collections (``tosca.artifacts.AnsibleGalaxy.collections ``)
203
203
to be installed and used in the playbooks::
204
204
@@ -255,8 +255,8 @@ some cloud providers, in general is better not to add it::
255
255
Policies & groups
256
256
^^^^^^^^^^^^^^^^^
257
257
258
- IM enables the definition of the specific cloud provider where the Compute nodes will be deployed in an hybrid deployment.
259
- For example, in the following code we assume that we have defined three computes nodes (compute_one, compute_two and compute_three).
258
+ IM enables the definition of the specific cloud provider where the Compute nodes will be deployed in a hybrid deployment.
259
+ For example, in the following code we assume that we have defined three compute nodes (compute_one, compute_two and compute_three).
260
260
We can create a placement group with two of them (compute_one and compute_two) and then set a placement policy with a cloud_id
261
261
(that must be defined in the :ref: `auth-file `), and create a second placement policy where we can set a different cloud provider
262
262
and, optionally, an availability zone::
@@ -285,10 +285,10 @@ Container Applications (Kubernetes connector)
285
285
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
286
286
287
287
IM also enables the definition of container applications to be deployed in a Kubernetes cluster.
288
- In the following example we can see how to define a container application (IM) that uses a
288
+ In the following example, we can see how to define a container application (IM) that uses a
289
289
ConfigMap for a configuration file. The IM application is connected with a MySQL backend
290
290
using the ``IM_DATA_DB `` environment variable. The MySQL container is defined with a Persistent
291
- Volume Claim (PVC) of 10GB. Furthermore the IM application specifies an endpoint to be published
291
+ Volume Claim (PVC) of 10GB. Furthermore, the IM application specifies an endpoint to be published
292
292
that will result in the creation of a Kubernetes Ingress.
293
293
294
294
...
@@ -384,14 +384,14 @@ Advanced Output values
384
384
The ``tosca.nodes.indigo.Compute `` node type adds a new
385
385
attribute named: ``ansible_output ``. It is a map that has one element per each IM
386
386
configuration step, so you can access it by name. The steps have the keyword
387
- ``tasks `` that is also a map that has one element per ansible task. In this case
388
- it can bes accessed using the task name as defined in the playbook. Finally
387
+ ``tasks ``, that is also a map that has one element per ansible task. In this case
388
+ it can be accessed using the task name as defined in the playbook. Finally
389
389
there is an ``output `` keyword that returns the output of the task.
390
390
In most of the cases the task is a ``debug `` ansible task that shows anything you
391
391
want to return.
392
392
393
- In the following example the specified task was a debug ansible task that shows the
394
- value of a internal defined value::
393
+ In the following example, the specified task was a debug ansible task that shows the
394
+ value of a internally defined value::
395
395
396
396
...
397
397
0 commit comments