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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
