Open Stack

Hi all.

In my opinion it is about things that can live in one form or another, because
in some cases there is a need to place an instance in the same place where its
block device is located or will be attached. Both solutions that let you do it,
I mean filter and weigher, have a right to life. A lot depends on the
requirements that are present when you start an instance:

1.  In the case when you want to put them together preferably, there should be
    a weigher. If that fails, then the user should not worry about it, the
    instance will be started though not as optimally as wanted.
2.  When it is important that they are together and nothing else is acceptable,
    then there should be a filter. Some applications that are built on top of
    OpenStack may require that instance must be together with a particular
    volume.

Thus, both the filter and the weighter can be used, and it would give a great
flexibility to choose what and how to use, but both options will require to
specify a particular volume via scheduler hints. On the other hand, it is
possible to use block_device_mapping, which allows to select several devices.
In the case of multiple devices it is not clear which of them to use for
affinity choice, this issue can be resolved in the same way through a
scheduler hint. Thus the special hint gives ability to use affinity more
generally.

--
Ilya Kharin
Software Engineer
OpenStack Services
Mirantis Inc.


On Jul 4, 2013, at 11:56 AM, Álvaro López García <alvaro.lopez.garcia at cern.ch> wrote:

> On Wed 03 Jul 2013 (18:24), Alexey Ovchinnikov wrote:
>> Hi everyone,
> 
> Hi Alexey.
> 
>> 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/
> 
> This is something we were eager to see and that we were also aiming to
> implement in the future, so, great job!
> 
>> 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?
> 
> I'd go with the weigher. We have some use cases for this volume
> affinity, but they always require to access to their data rather than
> failing. Moreover, the filter implies that the user has some knowledge
> on the infrastructure (i.e. that volumes and instances can be
> coallocated) and it is only available for LVM drivers, whereas the
> weigher should work transparently in all situations.
> 
> Cheers,
> -- 
> Álvaro López García                              aloga at ifca.unican.es
> Instituto de Física de Cantabria         http://alvarolopez.github.io
> Ed. Juan Jordá, Campus UC                      tel: (+34) 942 200 969
> Avda. de los Castros s/n
> 39005 Santander (SPAIN)
> _____________________________________________________________________
> "If you haven't used grep, you've missed one of the simple pleasures of
> life." -- Brian Kernighan
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev