Le 02/04/2015 03:19, Jay Pipes a écrit :
On 04/01/2015 12:31 PM, Duncan Thomas wrote:
On 1 April 2015 at 10:04, Joshua Harlow <[email protected]
<mailto:[email protected]>> wrote:
+1 to this. There will always be people who will want to work on fun
stuff and those who don't; it's the job of leadership in the
community to direct people if they can (but also the same job of
that leadership to understand that they can't direct everyone; it is
open-source after all and saying 'no' to people just makes them run
to some other project that doesn't do this...).
IMHO (and a rant probably better for another thread) but I've seen
to many projects/specs/split-outs (ie, scheduler tweaks, constraint
solving scheduler...) get abandoned because of cores saying this or
that is the priority right now (and this in all honesty pisses me
off); I don't feel this is right (cores should be leaders and
guides, not dictators); if a core is going to tell anyone that then
they better act as a guide to the person they are telling that to
and make sure they lead that person they just told "no"; after all
any child can say "no" but it takes a real man/woman to go the extra
distance...
So I think saying no is sometimes a vital part of the core team's role,
keeping up code quality and vision is really hard to do while new
features are flooding in, and doing architectural reworking while
features are merging is an epic task. There are also plenty of features
that don't necessarily fit the shared vision of the project; just
because we can do something doesn't mean we should. For example: there
are plenty of companies trying to turn Openstack into a datacentre
manager rather than a cloud (i.e. too much focus on pets .v. cattle
style VMs), and I think we're right to push back against that.
Amen to the above. All of it.
Right now there are some strong indications that there are areas we are
very weak at (nova network still being preferred to neutron, the amount
of difficultly people had establishing 3rd party CI setups for cinder)
that really *should* be prioritised over new features.
That said, some projects can be worked on successfully in parallel with
the main development - I suspect that a scheduler split out proposal is
one of them. This doesn't need much/any buy-in from cores, it can be
demonstrated in a fairly complete state before it is evaluated, so the
only buyi-in needed is on the concept.
Ha, I had to laugh at this last paragraph :) You mention the fact that
nova-network is still very much in use in the paragraph above (for
good reasons that have been highlighted in other threads). And yet you
then go on to suspect that a nova-scheduler split would something that
would be successfully worked on in parallel...
The Gantt project tried and failed to split the Nova scheduler out
(before it had any public or versioned interfaces). The "solver
scheduler" has not gotten any traction not because as Josh says "some
cores are acting like dictators" but because it doesn't solve the
right problem: it makes more complex scheduling placement decisions in
a different way from the Nova scheduler, but it doesn't solve the
distributed scale problems in the Nova scheduler architecture.
If somebody developed an external generic resource placement engine
that scaled in a distributed, horizontal fashion and that had
well-documented public interfaces, I'd welcome that work and quickly
work to add a driver for it inside Nova. But both Gantt and the solver
scheduler fall victim to the same problem: trying to use the existing
Nova scheduler architecture when it's flat-out not scalable.
Alright, now that I've said that, I'll wait here for the inevitable
complaints that as a Nova core, I'm being a dictator because I speak
my mind about major architectural issues I see in proposals.
And that's also why the more I'm reviewing, the more I'm thinking that
people need to have a basic understanding of all the Nova repository and
not only a specific asset if they want to provide a new feature, just
because of the technical debt and all the inherited interactions.
Take the scheduler as an example again : most of the commits related to
it are also impacting objects, cells, db migrations to quote the most
related.
I was originally pro giving a limited set of merge powers to subteams
for a specific codepath, but my personal experience made me think that
it can't work that way in Nova at the moment - just because everything
is intersected.
So, yeah, before kicking-off new features, we need at least people
enough aware of the global state to give their voice on if it's doable
or not. I don't want to say it would be a clique or a gang blessing good
people or bad people, just architects that have enough knowledge to know
if it will work - or not.
Good ideas can turn into bad implementations just because of the
existing tech debt. And there is nothing that we can avoid that, unless
we have mentors that can help us finding the right path.
Don't get me wrong : again, it's not giving more powers to people, it's
basically stating that cores are by definition people who have the
global knowledge.
My 2cts,
-Sylvain
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
