<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 8, 2013 at 8:53 AM, Ilya Kharin <span dir="ltr"><<a href="mailto:ikharin@mirantis.com" target="_blank">ikharin@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all.<br>
<br>
In my opinion it is about things that can live in one form or another, because<br>
in some cases there is a need to place an instance in the same place where its<br>
block device is located or will be attached. Both solutions that let you do it,<br>
I mean filter and weigher, have a right to life. A lot depends on the<br>
requirements that are present when you start an instance:<br>
<br>
1. In the case when you want to put them together preferably, there should be<br>
a weigher. If that fails, then the user should not worry about it, the<br>
instance will be started though not as optimally as wanted.<br>
2. When it is important that they are together and nothing else is acceptable,<br>
then there should be a filter. Some applications that are built on top of<br>
OpenStack may require that instance must be together with a particular<br>
volume.<br></blockquote><div><br></div><div>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. </div>
<div><br></div><div>Also I agree with Russell, I don't like scheduler hints. And don't want to add more if we can help it.</div><div><br></div><div>So my vote is make this a weight and not a filter.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thus, both the filter and the weighter can be used, and it would give a great<br>
flexibility to choose what and how to use, but both options will require to<br>
specify a particular volume via scheduler hints. On the other hand, it is<br>
possible to use block_device_mapping, which allows to select several devices.<br>
In the case of multiple devices it is not clear which of them to use for<br>
affinity choice, this issue can be resolved in the same way through a<br>
scheduler hint. Thus the special hint gives ability to use affinity more<br>
generally.<br>
<br>
--<br>
Ilya Kharin<br>
Software Engineer<br>
OpenStack Services<br>
Mirantis Inc.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Jul 4, 2013, at 11:56 AM, Álvaro López García <<a href="mailto:alvaro.lopez.garcia@cern.ch">alvaro.lopez.garcia@cern.ch</a>> wrote:<br>
<br>
> On Wed 03 Jul 2013 (18:24), Alexey Ovchinnikov wrote:<br>
>> Hi everyone,<br>
><br>
> Hi Alexey.<br>
><br>
>> for some time I have been working on an implementation of a filter that<br>
>> would allow to force instances to hosts which contain specific volumes.<br>
>> A blueprint can be found here:<br>
>> <a href="https://blueprints.launchpad.net/nova/+spec/volume-affinity-filter" target="_blank">https://blueprints.launchpad.net/nova/+spec/volume-affinity-filter</a><br>
>> and an implementation here:<br>
>> <a href="https://review.openstack.org/#/c/29343/" target="_blank">https://review.openstack.org/#/c/29343/</a><br>
><br>
> This is something we were eager to see and that we were also aiming to<br>
> implement in the future, so, great job!<br>
><br>
>> The filter works for LVM driver and now it picks either a host containing<br>
>> specified volume<br>
>> or nothing (thus effectively failing instance scheduling). Now it fails<br>
>> primarily when it can't find the volume. It has been<br>
>> pointed to me that sometimes it may be desirable not to fail instance<br>
>> scheduling but to run it anyway. However this softer behaviour fits better<br>
>> for weighter function. Thus I have registered a blueprint for the<br>
>> weighter function:<br>
>> <a href="https://blueprints.launchpad.net/nova/+spec/volume-affinity-weighter-function" target="_blank">https://blueprints.launchpad.net/nova/+spec/volume-affinity-weighter-function</a><br>
>><br>
>> I was thinking about both the filter and the weighter working together. The<br>
>> former<br>
>> could be used in cases when we strongly need storage space associated with<br>
>> an<br>
>> instance and need them placed on the same host. The latter could be used<br>
>> when<br>
>> storage space is nice to have and preferably on the same host<br>
>> with an instance, but not so crucial as to have the instance running.<br>
>><br>
>> During reviewing a question appeared whether we need the filter and<br>
>> wouldn't things be better<br>
>> if we removed it and had only the weighter function instead. I am not yet<br>
>> convinced<br>
>> that the filter is useless and needs to be replaced with the weighter,<br>
>> so I am asking for your opinion on this matter. Do you see usecases for the<br>
>> filter,<br>
>> or the weighter will answer all needs?<br>
><br>
> I'd go with the weigher. We have some use cases for this volume<br>
> affinity, but they always require to access to their data rather than<br>
> failing. Moreover, the filter implies that the user has some knowledge<br>
> on the infrastructure (i.e. that volumes and instances can be<br>
> coallocated) and it is only available for LVM drivers, whereas the<br>
> weigher should work transparently in all situations.<br>
><br>
> Cheers,<br>
> --<br>
> Álvaro López García <a href="mailto:aloga@ifca.unican.es">aloga@ifca.unican.es</a><br>
> Instituto de Física de Cantabria <a href="http://alvarolopez.github.io" target="_blank">http://alvarolopez.github.io</a><br>
> Ed. Juan Jordá, Campus UC tel: <a href="tel:%28%2B34%29%20942%20200%20969" value="+34942200969">(+34) 942 200 969</a><br>
> Avda. de los Castros s/n<br>
> 39005 Santander (SPAIN)<br>
> _____________________________________________________________________<br>
> "If you haven't used grep, you've missed one of the simple pleasures of<br>
> life." -- Brian Kernighan<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>