Ask Your Question
1

HEAT update failed on block volume operation

asked 2017-01-04 13:06:13 -0500

doka.ua gravatar image

updated 2017-01-05 02:08:01 -0500

Dear friends, again need your assistance.

Summary: HEAT stack update fails when adding new block volume to 'block_device_mapping_v2' section in OS::Nova::Server resource.

I'm trying, using Heat, manipulate VM's block volume allocation, using the following template:

  centos_v7:
    type: OS::Glance::Image
    properties:
      [ ... ]
      location: http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2

  din3_volume:
    type: OS::Cinder::Volume
    properties:
      size: 30
      name: din3_boot
      image: { get_resource: centos_v7 }

# Aux volume, will be used later in the example
  din3_aux:
    type: OS::Cinder::Volume
    properties:
      size: 15
      name: din3_aux

  din3_init:
    type: OS::Heat::MultipartMime
    properties: [ ... ]

  din3:
    type: OS::Nova::Server
    properties:
      flavor: { get_param: flavor }
      block_device_mapping_v2:
        - delete_on_termination: true
          swap_size: 512
        - delete_on_termination: false
          boot_index: 0
          volume_id: { get_resource: din3_volume }
      networks:
         - port: { get_resource: din3-i2e }
      user_data_format: SOFTWARE_CONFIG
      user_data: { get_resource: din3_init }

There are other resources in the stack and creation of stack ends with success and both volumes are exist in the stack:

doka/doka@doka.ua:~/heat $ openstack volume list
| e15795cb-bea1-4a3b-b910-d39b18541ca3 | din3_boot | in-use | 32 | Attached to din3 on /dev/vda
| f709ab08-0f9d-4ae3-9645-7af7e1ea9659 | din3_aux  | available |   16 |

As soon as I add din3_aux to "block_device_mapping_v2" section, changing nothing more:

  din3:
    type: OS::Nova::Server
    properties:
      flavor: { get_param: flavor }
      block_device_mapping_v2:
        - delete_on_termination: true
          swap_size: 512
        - delete_on_termination: false
          boot_index: 0
          volume_id: { get_resource: din3_volume }
        - delete_on_termination: true
          boot_index: 1
          volume_id: { get_resource: din3_aux }
      networks:
        - port: { get_resource: din3-i2e }
      user_data_format: SOFTWARE_CONFIG
      user_data: { get_resource: din3_init }

update of stack fails with the following message:

stack_status          | UPDATE_FAILED
stack_status_reason   | Resource CREATE failed: BadRequest: resources.din3: Invalid volume:
                        volume 'e15795cb-bea1-4a3b-b910-d39b18541ca3' status must be 'available'.
                        Currently in 'in-use' (HTTP 400)
                        (Request-ID: req-203313ac-e81d-42f5-8a56-c17ad02eb14f)

Of course, din3_volume is in use since VM is running and din3_volume is bootable one. Questions are:

1) is it a bug or a feature? :-)

2) adding new volume is atomic operation and can be successfully done using Openstack CLI - why same operation in Heat results in reconfiguration of existing volumes? Are there ways to make them atomic in Heat as well?

Any recommendations on how to avoid reconfiguration of block volume on update which don't touch this block volume are highly welcome.

Thanks!

edit retag flag offensive close merge delete

Comments

Please raise a bug.

zaneb gravatar imagezaneb ( 2017-01-06 09:00:31 -0500 )edit
doka.ua gravatar imagedoka.ua ( 2017-01-09 00:58:46 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2017-01-09 06:57:56 -0500

doka.ua gravatar image

Answer from HEAT team: "I think block_device_mapping_v2 property is not update_allowed. Therefore when you change them to add a additional device mapping, it would replace the server. Existing server is deleted only after the new one is created. Thefore the 'in-use' (HTTP 400) error. We could handle it better though by detaching first and reattaching to old server in case of rollback.

If you want to attach additional volume to an existing server, may be you can use OS::Cinder::VolumeAttachment instead?"

Actually, instead of updating block_device_mapping_v2 section with

  block_device_mapping_v2:
    [ ... ]
    - delete_on_termination: true
      boot_index: 1
      volume_id: { get_resource: din3_aux }

the following configuration works:

  din3_aux_attachment:
    type: OS::Cinder::VolumeAttachment
    properties:
      instance_uuid: { get_resource: din3 }
      volume_id: { get_resource: din3_aux }
      mountpoint: /dev/vdc

Thanks again to HEAT team for fast response.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2017-01-04 13:06:13 -0500

Seen: 693 times

Last updated: Jan 09 '17