Open Stack

On 10/4/2013 7:33 AM, Chris Friesen wrote:
> On 10/04/2013 04:11 AM, Caitlin Bestler wrote:
> >
> > On Oct 3, 2013 1:45 PM, "Chris Friesen" <chris.friesen at windriver.com
> > <mailto: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 <mailto: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.)
>
> >  >> *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.
>
> Booting an instance from a cinder volume is only one way of getting
> shared storage.  (And yes, any instance booting from a cinder volume
> could be considered to be on shared storage--but the existing code
> doesn't use that knowledge.)
>
> The compute node can mount a shared filesystem and store the instance
> files on it, and all instances on that compute node would be on shared
> storage.  The "evacuate" code currently requires the admin to specify
> whether the instance files are shared or not--which means the admin
> potentially needs to look up the instance, figure out what node it's on,
> and check whether the files are shared.  Interestingly, when a compute
> node comes back up it actually creates temporary files to see whether
> instances are shared or not so that it can delete the ones that aren't
> shared--it'd be way more efficient to just store that information once
> at instance creation.
>
> The existing "host-evacuate" command only works if all instances on a
> given compute node are either shared or not shared.  If some of them are
> local and some boot from cinder volumes then you have to evacuate them
> one at a time until the remaining ones are all of the same time.
>
> > 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?
>
> For the purposes of the "evacuate" command, this would be local storage
> because the thin volume (containing all the instance-specific data)
> would be lost if the compute node goes down.
>
> Maybe "on_shared_storage" is too generic, and "instance_shared_storage"
> would be more accurate.  I'm not hung up on the name, but I think it
> would be good for the instance itself to track whether or not its rootfs
> is persistent over compute node failure rather than forcing the admin to
> remember it.
>
> Chris
>
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.