Open Stack

On 09/05/2014 02:59 AM, Sylvain Bauza wrote:
> Le 05/09/2014 01:26, Jay Pipes a écrit :
>> On 09/04/2014 10:33 AM, Dugger, Donald D wrote:
>>> Basically +1 with what Daniel is saying (note that, as mentioned, a
>>> side effect of our effort to split out the scheduler will help but
>>> not solve this problem).
>>
>> The difference between Dan's proposal and the Gantt split is that
>> Dan's proposal features quite prominently the following:
>>
>> == begin ==
>>
>>  - The nova/virt/driver.py class would need to be much better
>>    specified. All parameters / return values which are opaque dicts
>>    must be replaced with objects + attributes. Completion of the
>>    objectification work is mandatory, so there is cleaner separation
>>    between virt driver impls & the rest of Nova.
>>
>> == end ==
>>
>> In other words, Dan's proposal above is EXACTLY what I've been saying
>> needs to be done to the interfaces between nova-conductor,
>> nova-compute, and nova-scheduler *before* any split of the scheduler
>> code is even remotely feasible.
>>
>> Splitting the scheduler out before this is done would actually not
>> "help but not solve this problem" -- it would instead further the
>> problem, IMO.
>>
>
> Jay, we agreed on a plan to carry on, please be sure we're working on
> it, see the Gantt meetings logs for what my vision is.

I've attended most of the Gantt meetings, except for a couple recent 
ones due to my house move (finally done, yay!). I believe we are mostly 
aligned on the plan of record, but I see no urgency in splitting out the 
scheduler. I only see urgency on cleaning up the interfaces. But, that 
said, let's not highjack Dan's thread here too much. We can discuss on 
IRC. I was only saying that Don's comment that splitting the scheduler 
out would help solve the bandwidth issues should be predicated on the 
same contingency that Dan placed on splitting out the virt drivers: that 
the internal interfaces be cleaned up, documented and stabilized.

<snip>

> So, this effort requires at least one cycle, and as Dan stated, there is
> urgency, so I think we need to identify a short-term solution which
> doesn't require refactoring. My personal opinion is what Russell and
> Thierry expressed, ie. subteam delegation (to what I call "half-cores")
> for iterations and only approvals for cores.

Yeah, I don't have much of an issue with the subteam delegation 
proposals. It's just really a technical problem to solve w.r.t. Gerrit 
permissions.

Best,
-jay