Open Stack

On Mon, Jul 8, 2013 at 8:53 AM, Ilya Kharin <ikharin at mirantis.com> wrote:

> 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.
>

I question how 'cloudy' an architecture that *requires* instances and
volumes be on the same node.  If we treat instances as ephemeral and
volumes as persistent having them live on the same node is a contradiction.

Also I agree with Russell, I don't like scheduler hints.  And don't want to
add more if we can help it.

So my vote is make this a weight and not a filter.


>
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/f4e5fbc9/attachment.html>