Open Stack

On 10/04/2013 12:06 PM, Caitlin Bestler wrote:

> You've covered some reasons why there might be an instance attribute,
>  but you still need to deal with getting the information about the
> underlying storage services from those storage services.
>
> Don't make assumptions about what a storage service is doing.
>
> Don't expect the storage services to export their characteristics
> beyond the scope that they would be focused upon.

I don't think we need to make many assumptions.

A given "compute" service will be configured with a single location for 
instance storage.  That location will be either shared or local 
depending on how the compute node is set up at commissioning.  This 
shared/local value could be stored in the config file alongside the 
location, and the compute service would read it in at startup.  Any 
instance started up on that compute node would have its 
"instance_shared_storage" value set by the compute node.

Block storage is by definition shared, so any instance booting off a 
cinder volume would be considered to be on shared storage even if the 
compute node's instance files are normally not shared.

The one assumption here is that if an instance is booted up on shared 
storage, then that storage is accessible from any other compute node 
that the instance could be migrate/evacuate to.  For larger 
installations this could be enforced by using host aggregates to group 
together the hosts that share a given instance storage filesystem.

Chris