Open Stack

Le 05/09/2014 14:48, Jay Pipes a écrit :
> 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.
>

Well, that just requires new Gerrit groups and a new label (like 
Subteam-Approved) so that members of this group could just 
+Subteam-Approved if they're OK (here I imagine 2 people from the group 
labelling it)

Of course, all the groups could have permissions to label any file of 
Nova, but here we can just define a gentleman's agreement, like we do 
for having two +2s before approving.

That would say that cores could just search using Gerrit with 
'label:Subteam-Approved>=1'

-Sylvain

> Best,
> -jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev