[openstack-dev] [nova] RFC: adding "on_shared_storage" field to instance

Caitlin Bestler caitlin.bestler at nexenta.com
Fri Oct 4 10:11:34 UTC 2013


On Oct 3, 2013 1:45 PM, "Chris Friesen" <chris.friesen at windriver.com> wrote:
>
> On 10/03/2013 02:02 PM, Caitlin Bestler wrote:
>>
>>
>>
>> On October 3, 2013 12:44:50 PM Chris Friesen
>> <chris.friesen at windriver.com> wrote:
>>>
>>>
>>> I was wondering if there is any interest in adding an
>>> "on_shared_storage" field to the Instance class.  This would be set
>>> once at instance creation time and we would then be able to avoid
>>> having the admin manually pass it in for the various API calls
>>> (evacuate/rebuild_instance/migration/etc.)
>>>
>>> It could even be set automatically for the case of booting off block
>>> storage, and maybe we add a config flag indicating that a given
>>> compute node is using shared storage for its instances.
>>>
>>> This would also allow for "nova host-evacuate" to work properly if
>>> some of the instances are on unshared storage and some are booting
>>> from block storage (which is shared).  As it stands, the host-evacuate
>>> command assumes that they're all the same.
>>>
>>> Thoughts?
>>>
>>> Chris
>>
>>
>> *What* is on shared storage?
>>
>> The boot drive?
>> A snapshot of the running VM?
>
>

Meaning that this is not an attribute of the instance, it is an attribute
of the Cinder drive, or more precisely from the Volume
Driver responsible for that drive.

I believe reporting of attributes that are of potential meaning to
users of a drive is a feature that should be added (And documented) for all
Volume Drivers. But drive vendors want one
place to report these things.

Further the question can actually be complex. Is a thin local volume backed
by a remote volume "local"? If so, at what hit rate for the local cache?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131004/505ec76e/attachment.html>


More information about the OpenStack-dev mailing list