tacker

Persist volume and attach created volume

Asked by Anshul Sehgal

Hi Experts,

Is there a way to persist volumes by defining any property in tosca template itself.(Without human intervention).

I have tested creating vnf using method mentioned at https://docs.openstack.org/tacker/latest/reference/block_storage_usage_guide.html
and it works fine.

It creates volume and attach it to vnf, but it also delete the volume when vnf is terminated.

I also see some discussion on https://review.opendev.org/#/c/698477/ that tosca.nodes.BlockStorage already have volume_id property .(https://review.opendev.org/#/c/698477/1/tacker/tests/unit/vnfm/infra_drivers/openstack/data/sample-tosca-vnfd-existing-block-storage.yaml)

But when I tested template with volume_id, at the time of creating vnfd itself, it tells
MissingRequiredFieldError: "properties" of template "VB1" is missing required field "['size']"

And if I provide size field, vnfd gets created, but when deploying vnf, getting below error.
ERROR: Property error: : resources.VB1.properties: : Unknown Property volume_id

I am not sure if this property is working as this is not on the official documents at openstack site.

If this feature is working, please guide how it can be used.

Expected:
There should be a way to opt between whether or not volume to be deleted after vnf deletion. Also to attach already created volume to a vnf.

Setup Info:
============
Deployment: Kolla-ansible
Version: stable/train
Host OS: Centos 7

Thanks in advance.

Question information

Language:
English Edit question
Status:
Expired
For:
tacker Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Toshiaki Takahashi (takahashi-tsc) said : 		#1

Your investigate is correct.
Now, "size" cannot be omitted, and the "volume_id" property does not work correctly.
i.e. we can only use volume which is created when VNF is created and deleted when VNF is terminated.

Development of the patch which you show is now stopped...
Would you like Tacker community to proceed with develop the feature?
If you have strong requirement, we can discuss it.
In the discussion, I would like to discuss how persistent volumes are created and how the volumes' lifecycle should work in detail.

Revision history for this message
Anshul Sehgal (anshul-sehgal) said : 		#2

Hi Toshiaki,

Thanks for your revert.

Yes, there should be an option to persist and re-use/attach the created volume.

Problem case:
---------------------------
Generally whatever VNF is launched, it is launched with initial 10GB of space for OS booting and other stuff. And VNF/application saves its data on mounted volume. So if it is required to start the VNF from last point of time, it is required to persist the data.

At present, even in ping monitoring, old volume is deleted and re-created.(With volume name containing RESPAWN-(count) in that.

Expectation:
-----------------------

1) how persistent volumes are created?
     I think current approach is good where volume is created when VNF is deployed. We can add some properties to it such as what should be the name of created volume(As we specify name of VDU) and whether it should be terminated with termination of VNF.

2) volumes' lifecycle should work in detail?
     Bind volume back to the VNF using volume name. Volume-id is also good, but volume-name will be more handy as user knows the volume name which they created in previous steps.
     Also if possible, there can be an option( Create new volume if not exist). if the details specified for binding the volume does not match any existing volume, then create new volume with specified details.
     If autoscaling case of VDUs should also be considered, we can have option like offset to the name of the volume. For example, app1-vol-0 will be offset by 1 for new auto scaled instance. So new volume for 2nd instance will be created as app1-vol-1. I am not sure how to provide a way to bind them back to scaled instance.

I tried to cover major points. I request to guide you what other points/cases should also be mentioned.

If everyone is following any other approach to overcome the problem, I am happy to use that. But that is not suggested anywhere.

Revision history for this message
Toshiaki Takahashi (takahashi-tsc) said : 		#3

Thank you for explaining your expectations!
We discussed re-starting development for attach created volume.

https://etherpad.opendev.org/p/Tacker-PTG-Wallaby
https://review.opendev.org/#/c/759361/

I have 1 question. Could you tell me use cases for autoscaling more in detail?
Does it mean that you prepare as many Persistent Volumes as VDUs are scaled before instantiation?

Revision history for this message
Anshul Sehgal (anshul-sehgal) said : 		#4

Hi Sir,

Sorry for delay in reply.

If we have a vdu with volume attached, then most likely its scaled instance would also require some space in same partition.

We can have volumes pre-created for autoscaled instances(Like 3 or 4 volumes). So whenever a new instance get scaled, it gets attached to its volume.

Otherwise if any better approach is there at present in practice, please suggest that.

Revision history for this message
Launchpad Janitor (janitor) said : 		#5

This question was expired because it remained in the 'Open' state without activity for the last 15 days.