On Mon, Jul 8, 2013 at 8:53 AM, Ilya Kharin <[email protected]> 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 < > [email protected]> 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 [email protected] > > 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
