Open Stack

Hi all,

Russell, I agree with all of your remarks, and especially with the
fact that placement details "have to be avoided" to be exposed to
users.

However I see a possible use case for the filter. For instance, if we
consider the BP "Support for multiple active scheduler drivers" (
https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers
): a cloud provider may want to provide a specific class of services
(on a dedicated aggregate) for users who wants to ensure that both
volumes and instances are on the same host and use the weight function
for all the other hosts.
Does it make sense?

Regards,
Jérôme

On Wed, Jul 3, 2013 at 5:54 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev