libvirt lvm volumes based on instance['name'] not instance['uuid']

[Sean Dague]

because libvirt lvm volumes are based on instance['name'], it means that the actual names used in lvm storage are based on an operator configuration variable: instance_name_template

the default is 'instance-%08x'

however this is site changable, and changable at any time. This creates 2 failure modes.

#1) operator changes this, the result is all volumes created before the change are no longer able to be cleaned up by nova

#2) operator has changed this to something that includes end user input, like %(display_name), which would allow one user to impact another (use A has display name "bob", user B has displayname "bob_joe") because of https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1068

specifically:

            pattern = '%s_' % instance['name']

            def belongs_to_instance(disk):
                return disk.startswith(pattern)

#2 is a non default situation, and requires specific config by an adminstrator and specific naming by users, but it should be protected against.

A much better approach would be to use instance['uuid'] which has no operator or user impact on naming.

[Matt Riedemann (mriedem)]

There was a similar fix for rbd images on master: https://review.openstack.org/#/c/44640/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/76968

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/76968
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d9a5a80bc06f7a25c259ff763a59dffd9514371e
Submitter: Jenkins
Branch: master

commit d9a5a80bc06f7a25c259ff763a59dffd9514371e
Author: Sean Dague <email address hidden>
Date: Thu Feb 27 15:57:17 2014 -0500

    Use uuid instead of name for lvm backend

    Because libvirt lvm volumes are based on instance['name'], it means
    that the actual names used in lvm storage are based on an operator
    configuration variable: instance_name_template (default is
    'instance-%08x').

    However this is site changeable, and changeable at any time. This
    creates 2 failure modes.

    1. Operator changes this, the result is all volumes created before the
    change are no longer able to be cleaned up by nova

    2. Operator has changed this to something that includes end user
    input, like %(display_name), which would allow one user to impact
    another (user A has display name "bob", user B has display name
    "bob_joe")

    This changes the lvm backend to use instance['uuid'] as it's
    identifier which we know is unique, non overlapping, and not
    changeable based on whims of site policy.

    It also provides limited backwards compatibility for cleaning up old
    disks if the installation was using the default template (which is
    safe), otherwise it logs a warning about possibly leaking a disk which
    will need to be manually cleaned up. That should be removed once we
    open the Juno tree.

    UpgradeImpact - while there is no operator action required to upgrade
    over this change, if the nova install included a non default value for
    instance_name_template then old lvm volumes will need to be cleaned up
    manually after old guests are destroyed.

    Change-Id: Ib36b962971fd1f66ea9a0818e91fec59e118e686
    Closes-Bug: #1285735