1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
.. Licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
.. _ONAP Heat Cinder Volumes:
ONAP Heat Cinder Volumes
----------------------------
Cinder Volumes are created with the heat resource OS::Cinder::Volume.
As stated in :need:`R-46119`, :need:`R-90748`, :need:`R-03251`, a
VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume
**MAY** be defined in a Base Module, Incremental Module, or Cinder
Volume Module.
ONAP supports the independent deployment of a Cinder volume via separate
Heat Orchestration Templates, the Cinder Volume module. This allows the
volume to persist after VNF deletion so that they can be reused on
another instance (e.g., during a failover activity).
A Base Module or Incremental Module may have a corresponding volume
module. Use of separate volume modules is optional. A Cinder volume may
be embedded within the Base Module or Incremental Module if persistence
is not required.
If a VNF Base Module or Incremental Module has an independent volume
module, the scope of volume templates must be 1:1 with Base module or
Incremental module. A single volume module must create only the volumes
required by a single Incremental module or Base module.
As stated in :need:`R-11200`, a VNF's Cinder Volume Module, when it exists,
**MUST** be 1:1 with a Base module or Incremental module. That is,
A single volume module must create only the volumes required by a
single Incremental module or Base module.
As stated in :need:`R-30395`, a VNF's Cinder Volume Module **MAY** utilize
nested heat.
As stated in :need:`R-89913`, a VNF's Heat Orchestration Template's Cinder Volume
Module Output Parameter(s) **MUST** include the
UUID(s) of the Cinder Volumes created in template,
while others **MAY** be included.
As stated in :need:`R-07443`, a VNF's Heat Orchestration Templates' Cinder Volume
Module Output Parameter's name and type **MUST** match the input parameter
name and type in the corresponding Base Module or Incremental Module unless
the Output Parameter is of the type ``comma_delimited_list``,
then the corresponding input parameter **MUST** be declared as type ``json``.
A single volume module must create only the volumes
required by a single Incremental module or Base module.
The following rules apply to independent volume Heat templates:
.. req::
:id: R-79531
:target: VNF
:keyword: MUST
The VNF Heat Orchestration Template **MUST** define
"outputs" in the volume template for each Cinder volume
resource universally unique identifier (UUID) (i.e. ONAP
Volume Template Output Parameters).
- The VNF Incremental Module or Base Module must define input
parameters that match each Volume output parameter (i.e., ONAP Volume
Template Output Parameters).
- ONAP will supply the volume template outputs automatically to the
bases/incremental template input parameters.
- Volume modules may utilize nested Heat templates.
Optional Property availability_zone
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. req::
:id: R-25190
:target: VNF
:keyword: SHOULD NOT
:updated: casablanca
A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
**SHOULD NOT** declare the property ``availability_zone``.
If the property is used, the value **MUST**
be enumerated in the environment file and must be set to ``nova``, which
is the default. There are no requirements on the parameter naming
convention with the exception that the naming convention **MUST NOT** be the
same as the ``OS::Nova::Server`` property ``availability_zone`` (i.e.,
``availability_zone_{index}``).
Optional Property volume_type
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OpenStack supports multiple volume types. If the ``OS::Cinder::Volume``
optional property ``volume_type`` is not specified, the OpenStack default
``volume type`` is used. If a specific volume type is required, the property
is used and the value **MUST** be enumerated in the environment file. There
are no requirements on the parameter naming convention.
Cinder Volume Examples
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*Examples: Volume Template*
A VNF has a Cinder volume module, named incremental_volume.yaml,
that creates an independent Cinder volume for a VM in the module
incremental.yaml. The incremental_volume.yaml defines a parameter in
the output section, dns_volume_id_0 which is the UUID of the cinder volume.
dns_volume_id_0 is defined as a parameter in incremental.yaml.
ONAP captures the UUID value of dns_volume_id_0 from the volume module
output statement and provides the value to the incremental module.
Note that the example below is not a complete Heat Orchestration
Template. The {vm-type} has been defined as "dns".
incremental_volume.yaml
.. code-block:: yaml
parameters:
vnf_name:
type: string
dns_volume_size_0:
type: number
...
resources:
dns_volume_0:
type: OS::Cinder::Volume
properties:
name:
str_replace:
template: VNF_NAME_volume_0
params:
VNF_NAME: { get_param: vnf_name }
size: {get_param: dns_volume_size_0}
...
outputs:
dns_volume_id_0:
value: {get_resource: dns_volume_0}
...
incremental.yaml
.. code-block:: yaml
parameters:
dns_server_0:
type: string
dns_volume_id_0:
type: string
...
resources:
dns_server_0:
type: OS::Nova::Server
properties:
name: {get_param: dns_name_0}
networks:
...
dns_volume_attach_0:
type: OS::Cinder::VolumeAttachment
properties:
instance_uuid: { get_resource: dns_server_0 }
volume_id: { get_param: dns_volume_id_0 }
|
