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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
