Cinder Volume Recreation Toggle in v1 Heal
This proposal adds an option to enable or disable Cinder volume recreation when issuing a v1 Heal request. Implements: blueprint v1-heal-cinder-volume Change-Id: Ie0c57dd36217365b2db87bfa3a6eb184bcd95aaf Signed-off-by: Hitomi Koba <hi-koba@kddi.com>
This commit is contained in:
@@ -22,6 +22,7 @@ Specifications
|
||||
:glob:
|
||||
:maxdepth: 2
|
||||
|
||||
specs/2025.2/index
|
||||
specs/2025.1/index
|
||||
specs/2024.2/index
|
||||
specs/2024.1/index
|
||||
|
9
specs/2025.2/index.rst
Normal file
9
specs/2025.2/index.rst
Normal file
@@ -0,0 +1,9 @@
|
||||
============================
|
||||
Tacker 2025.2 Specifications
|
||||
============================
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
*
|
124
specs/2025.2/placeholder.rst
Normal file
124
specs/2025.2/placeholder.rst
Normal file
@@ -0,0 +1,124 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================
|
||||
(Placeholder Spec)
|
||||
==================
|
||||
|
||||
This file is just a placeholder for the specs directory.
|
||||
It will be removed soon after some spec is merged.
|
||||
|
||||
The latest spec template is found at ``specs/template.rst``
|
||||
in the ``tacker-specs`` repository.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Sphinx toctree complains if no file exists in a directory
|
||||
specified in toctree glob.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
None
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Add this file. Please remove later when the another spec is approved.
|
||||
|
||||
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)
|
||||
-----------
|
||||
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
None
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
None
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
None
|
174
specs/2025.2/v1-heal-cinder-volume.rst
Normal file
174
specs/2025.2/v1-heal-cinder-volume.rst
Normal file
@@ -0,0 +1,174 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
============================================================
|
||||
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. [#v2_heal]_ )
|
||||
|
||||
By configuring these two parameters, users can flexibly adjust the behavior
|
||||
to suit their operational requirements.
|
||||
|
||||
Example of ``tacker.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[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:
|
||||
|
||||
.. code-block::
|
||||
|
||||
openstack vnflcm heal --vnfc-instance <vnfc_id> --additional-param-file <file_path> -- <vnflcm_id>
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"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 the ``heal_vnfc_block_storage`` and ``heal_include_block_storage_key``
|
||||
config value and branch logic accordingly.
|
||||
|
||||
* Modify other related parts as needed.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Add unit tests.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
* Configuration Options [#conf_options]_
|
||||
* ETSI NFV-SOL VNF Healing (v1) [#v1_heal]_
|
||||
* NFV Orchestration API Reference (v1) [#v1_api_ref]_
|
||||
* Command-Line Interface Reference (v1) [#v1_cli_ref]_
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#v2_heal] https://docs.openstack.org/tacker/latest/user/v2/vnf/heal/index.html#vnf-healing-procedure
|
||||
.. [#conf_options] https://docs.openstack.org/tacker/latest/configuration/config.html#vnf-lcm
|
||||
.. [#v1_heal] https://docs.openstack.org/tacker/latest/user/etsi_vnf_healing.html#vnf-healing-procedure
|
||||
.. [#v1_api_ref] https://docs.openstack.org/api-ref/nfv-orchestration/v1/vnflcm.html#heal-a-vnf-instance
|
||||
.. [#v1_cli_ref] https://docs.openstack.org/tacker/latest/cli/cli-etsi-vnflcm.html#heal-vnf
|
Reference in New Issue
Block a user