Open Stack

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?

> 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