Option to Enable/Disable Cinder Volume Recreation in v1 Heal¶
https://blueprints.launchpad.net/tacker/+spec/v1-heal-cinder-volume
This specification proposes adding an option to enable or disable Cinder volume recreation when issuing a v1 Heal request.
Problem description¶
The current v1 Heal request always recreates the specified VNFC instance along with its related Cinder storage resources, which is not flexible for users who want to keep their storage data. The v2 Heal request already provides an option to control this behavior.
Proposed change¶
The existing additionalParams
field in the v1 Heal request will be extended
to include a new parameter that allows users to choose whether to recreate
the Cinder storage resources.
To achieve this, two new parameters will be added under [vnf_lcm]
in
tacker.conf
.
If neither parameter is defined, the existing behavior will remain unchanged.
heal_vnfc_block_storage
sets the default behavior. If the Heal request does
not specify it, this value is used.
heal_include_block_storage_key
sets the parameter name that can be used in
the additionalParams
field of the Heal request. This allows users to align
the request format with v2 or choose a different name if preferred.
(Setting this to “all” will match the v2 request format. [1] )
By configuring these two parameters, users can flexibly adjust the behavior to suit their operational requirements.
Example of tacker.conf
:
[vnf_lcm]
heal_vnfc_block_storage = false
heal_include_block_storage_key = heal_include_storage # customized name
In this case, Example of Heal request with tacker-cli and additional-param:
openstack vnflcm heal --vnfc-instance <vnfc_id> --additional-param-file <file_path> -- <vnflcm_id>
{
"additionalParams":
{
"heal_include_storage": true
}
}
In this case, the storage will only be recreated if explicitly specified in the Heal request. This means it is suitable for environments where most users prefer to keep their storage data during a heal operation.
Alternatives¶
None
Data model impact¶
None
REST API impact¶
None
Security impact¶
None
Notifications impact¶
None
Other end user impact¶
None
Performance Impact¶
None
Other deployer impact¶
None
Developer impact¶
None
Upgrade impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
Hitomi Koba <hi-koba@kddi.com>
Work Items¶
Consider making
heal_include_block_storage_key
configurable, based on ETSI-NFV direction (under discussion).Update Docs (Documentation Impact).
Update OpenStack Driver (
tacker/nfvo/drivers/vim/openstack_driver.py
) to check theheal_vnfc_block_storage
andheal_include_block_storage_key
config value and branch logic accordingly.Modify other related parts as needed.
Dependencies¶
None
Testing¶
Add unit tests.