Excerpts from Boris Pavlovic's message of 2015-10-11 01:14:08 -0700:
> Clint,
> There are many PROS and CONS in both of approaches.
> Reinventing wheel (in this case it's quite simple task) and it gives more
> flexibility and doesn't require
> usage of ZK/Consul (which will simplify integration of it with current
> system)
> Using ZK/Consul for POC may save a lot of time and as well we are
> delegating part of work
> to other communities (which may lead in better supported/working code).
> By the way some of the parts (like sync of schedulers) stuck on review in
> Nova project.
> Basically for POC we can use anything and using ZK/Consul may reduce
> resources for development
> which is good.

Awesome, I think we are aligned.

So, let's try and come up with a set of next steps to see a POC.

1) Let's try and get some numbers at the upper bounds of the current
scheduler with one and multiple schedulers. We can actually turn this
into a gate test harness, as we don't _actually_ care about the vms,
so this is an excellent use for the fake virt driver. In addition to
"where it breaks", I'd also like to see graphs of what it does to the
database and MQ bus. This aligns with the performance discussions that
will be happening as a sub-group of the large operators group, so I
think we can gather support for such an effort there.

2) Let's resolve which backend thing to use in the DLM spec. I have a
strong desire to consider the needs of DLM and the needs of scheduling
together. If the DLM discussion is tied, or nearly tied, on a few
choices, but one of the choices is better for the scheduler, it may
help the discussion. It may also hurt if one is more desirable for DLM,
and one is more desirable for scheduling. My gut says that they'll all
be suitable for both of these tasks, and it will boil down to binary
access and operator preference.

3) POC goes to the first person with free time. It's been my experience
that people come free at somewhat unexpected intervals, and I don't
want anyone to wait too long for consensus. So if anyone who agrees
with this direction gets time, I say, write a spec, get it out there,
and experiment with code.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to