On Thu, Jul 11, 2013 at 9:12 AM, Álvaro López García <[email protected]> wrote: > On Wed 10 Jul 2013 (13:10), Joe Gordon wrote: >> 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. > > I do fully agree with this. In the worst case, a machine requiring > affinity with a volume that is stored in a compute-node without enough > room will never boot.
I am wondering what is the difference between the filter we are discussing and, for instance, the SameHostFilter. Correct me if I'm wrong, however, SameHostFilter selects computes where specifics instances are running. If these computes have not enough free capacity, the requested instance will not boot. Here, this is not the same case with volume? The filter selects a compute where a specific volume is stored. If the compute is not available, the requested instance will not boot too. Does this make sense? Thanks, Jérôme _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
