Open Stack

Clint Byrum wrote:
> 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.

Just a related thought/question. It really seems we (as a community) 
need some kind of scale testing ground. Internally at yahoo we were/are 
going to use a 200 hypervisor cluster for some of this and then expand 
that into 200 * X by using nested virtualization and/or fake drivers and 
such. But this is a 'lab' that not everyone can have, and therefore 
isn't suited toward community work IMHO. Has there been any thought on 
such a 'lab' that is directly in the community, perhaps trystack.org can 
be this? (users get free VMs, but then we can tell them this area is a 
lab, so don't expect things to always work, free isn't free after all...)

With such a lab, there could be these kinds of experiments, graphs, 
tweaks and such...

>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev