[openstack-dev] [nova] volume affinity filter for nova scheduler
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:
> and an implementation here:
> 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:
> 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
> 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.
More information about the OpenStack-dev