- Follow new PTI building docs - Add dir for Stein specs - Remove skeleton.rst file because the template is enough - Remove archive specs because they are invalid. - Remove test_tiltles.py because it is useless (no actuall check the spec files), instead, enable pep8 and waring-as-error for .rst files, clear error those files. - Add placeholder.rst for stein/rocky dir, if not they will show error when building docs, delete them when it has approved specs. Change-Id: I8c387c0a480844b111562a9e77eac6ab26c58bce
7.0 KiB
Executable File
Support persistent block storage in Tacker TOSCA
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/tacker/+spec/persistent-block-storage
This spec is to describe a TOSCA template for Cinder volume, and map the new TOSCA attributes to Heat's Cinder volume.
Problem description
Currently Tacker doesn't have many storage related attributes exposed in its TOSCA template. VDU disk_size is probably the only thing. We don't have support for attaching a persistent virtual storage (like Cinder volume) to Tacker VDU. Sometimes, VDU also needs 'boot from volume' feature.
Background technology
Now in TOSCA template, it supports creating VDU only with volume size, not supports booting from volume and specifying whether to delete the created volumesif the VDU is deleted.
Heat introduction
Heat now supports block storage. The usage is below:
- Create a new block storage volume
resources:
my_new_volume:
type: OS::Cinder::Volume
properties:
size: 10
- Create a bootable volume from an existing image
resources:
my_new_bootable_volume:
type: OS::Cinder::Volume
properties:
size: 10
image: ubuntu-trusty-x86_64
- Create new volumes from another existing volume
resources:
another_volume:
type: OS::Cinder::Volume
properties:
source_volid: 2fff50ab-1a9c-4d45-ae60-1d054d6bc868
- Create a new volume from another existing volume snapshot
resources:
another_volume:
type: OS::Cinder::Volume
properties:
snapshot_id: 2fff50ab-1a9c-4d45-ae60-1d054d6bc868
- Create a new volume from another existing volume backup
resources:
another_volume:
type: OS::Cinder::Volume
properties:
backup_id: 2fff50ab-1a9c-4d45-ae60-1d054d6bc868
- Create a new volume, and create an instance with this volume attached
resources:
new_volume:
type: OS::Cinder::Volume
properties:
size: 1
new_instance:
type: OS::Nova::Server
properties:
flavor: m1.small
image: ubuntu-trusty-x86_64
volume_attachment:
type: OS::Cinder::VolumeAttachment
properties:
volume_id: { get_resource: new_volume }
instance_uuid: { get_resource: new_instance }
7. Boot an instance from a volume and specify whether to delete the volume when the instance is deleted
resources:
bootable_volume:
type: OS::Cinder::Volume
properties:
size: 10
image: ubuntu-trusty-x86_64
instance:
type: OS::Nova::Server
properties:
flavor: m1.small
networks:
- network: private
block_device_mapping:
- device_name: vda
volume_id: { get_resource: bootable_volume }
delete_on_termination: false
Proposed change
1. Attaching a volume in TOSCA template In this case, the instance boot from an image, with a new created volume attached.
We introduce two new nodes, named VB and CB. VB defines a block storage, while CB describes the relationship between VDU and VB. VB will be deleted when the VDU is removed. One TOSCA template can support multiple VBs and CBs.
topology_template:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
properties:
image: centos
flavor: centos
CP1:
type: tosca.nodes.nfv.CP.Tacker
requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU1
VL1:
type: tosca.nodes.nfv.VL
VB1:
type: tosca.nodes.BlockStorage
properties:
size: 10 GB
CB1:
type: tosca.nodes.BlockStorageAttachment
properties:
location: /dev/vdb
requirements:
- virtualBinding:
node: VDU1
- virtualAttachment:
node: VB1
2. TOSCA for boot from volume In this case, the instance boot from a volume. The volume can be created from many different material, e.g. from a image.
Same with 1, we introduce a node named VB to define a block storage. In the requirement section of VDU node, we use local_storage to define the boot volume. 'delete_on_termination' can be configured to determine whether to delete the volume when VDU deleting.
topology_template:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
properties:
flavor: centos
requirements:
- local_storage:
node: VB1
relationship:
type: tosca.relationships.AttachesTo
location: /dev/vdb
delete_on_termination: false
CP1:
type: tosca.nodes.nfv.CP.Tacker
requirements:
- virtualLink:
node: VL1
- virtualBinding:
node: VDU1
VL1:
type: tosca.nodes.nfv.VL
VB1:
type: tosca.nodes.BlockStorage
properties:
size: 10 GB
image: ubuntu-trusty-x86_64
3. VDU scaling scenario A volume can only be attached to one instance in current nova/cinder realization. In tacker vnf scaling scenario, a VDU may have many instantiated instances. So in heat, we need create multiple volumes for each instances. Unfortunately, heat does not support it.
So we should verify the tosca template have no scaling policies when block storage exists.
Alternatives
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
Implementation
Assignee(s)
- Primary assignee:
-
Zhou Zhihong<zhouzhihong@cmss.chinamobile.com>
- Other contributors:
-
Yan Xing an<yanxingan@cmss.chinamobile.com>
Work Items
- Add tosca template samples for block storage
- Add codes to translate tosca template to HOT
- UT testcase
- FT testcase
- devref doc
Dependencies
None
Testing
None
Documentation Impact
None