Open Stack

Le 05/09/2014 15:11, Jay Pipes a écrit :
> On 09/05/2014 08:58 AM, Sylvain Bauza wrote:
>> 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)
>
> And what about code that crosses module boundaries? Would we need a 
> LibvirtSubteamApproved, SchedulerSubteamApproved, etc?
>

Luckily not. I think we only need one more label (we only have 3 now : 
Verified, Code-Review, Approved).

Here the key thing is having a search label that cores can consume 
because they know that this label is worth of interest. If something is 
crosses module, then that's something that probably a core would help.

For example, if I'm an API halfcore, I can subteam-approve all the 
changes related to the API itself (so that encourages small and readable 
patches btw.) but I leave my turn if I'm looking at something I don't 
know enough (or I provide +1)

The porting idea is to encourage reviewing because the step is not so 
high as if I wanted to be core. On the other hand, if an halfcore is 
becoming enough trustable (because he also provides good +1s for other 
areas and is enough involved in the release process), then this folk is 
a good candidate for becoming core.


As you identified, most of the proposal is based on gentle-person 
agreement because Gerrit is not enough flexible for doing that (although 
since 2.8, you can search all patches related to a path, like 
file:^nova/scheduler/*)

-Sylvain
>> 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.
>
> Yes, it would be a gentle-person's agreement. :) Gerrit cannot enforce 
> this kind of policy, that's what I was getting at.
>
>> That would say that cores could just search using Gerrit with
>> 'label:Subteam-Approved>=1'
>
> Interesting, yes, that would be useful.
>
> -jay
>
>> -Sylvain
>>
>>> Best,
>>> -jay
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev