[openstack-dev] [nova] volume affinity filter for nova scheduler

Russell Bryant rbryant at redhat.com
Wed Jul 3 15:54:55 UTC 2013

On 07/03/2013 10:24 AM, Alexey Ovchinnikov wrote:
> Hi everyone,
> for some time I have been working on an implementation of a filter that
> would allow to force instances to hosts which contain specific volumes.
> A blueprint can be found here:
> https://blueprints.launchpad.net/nova/+spec/volume-affinity-filter
> and an implementation here:
> https://review.openstack.org/#/c/29343/
> The filter works for LVM driver and now it picks either a host
> containing specified volume
> or nothing (thus effectively failing instance scheduling). Now it fails
> primarily when it can't find the volume. It has been
> pointed to me that sometimes it may be desirable not to fail instance
> scheduling but to run it anyway. However this softer behaviour fits better
> for weighter function. Thus I have registered a blueprint for the
> weighter function:
> https://blueprints.launchpad.net/nova/+spec/volume-affinity-weighter-function
> I was thinking about both the filter and the weighter working together.
> The former
> could be used in cases when we strongly need storage space associated
> with an 
> instance and need them placed on the same host. The latter could be used
> when 
> storage space is nice to have and preferably on the same host
> with an instance, but not so crucial as to have the instance running.
> During reviewing a question appeared whether we need the filter and
> wouldn't things be better
> if we removed it and had only the weighter function instead. I am not
> yet convinced
> that the filter is useless and needs to be replaced with the weighter,
> so I am asking for your opinion on this matter. Do you see usecases for
> the filter,
> or the weighter will answer all needs?

Thanks for starting this thread.

I was pushing for the weight function.  It seems much more appropriate
for a cloud environment than the filter.  It's an optimization that is
always a good idea, so the weight function that works automatically
would be good.  It's also transparent to users.

Some things I don't like about the filter:

 - It requires specifying a scheduler hint

 - It's exposing a concept of co-locating volumes and instances on the
same host to users.  This isn't applicable for many volume backends.  As
a result, it's a violation of the principle where users ideally do not
need to know or care about deployment details.

Russell Bryant

More information about the OpenStack-dev mailing list