> On Apr 1, 2015, at 7:19 PM, Jay Pipes <[email protected]> wrote:
> 
> 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.

Isn't this last statement the crux of the perception issue?  You're not a 
dictator because you're a core, you're a dictator because you're saying no (and 
I mean that in a good way.) I'd assume that any -1 with a strong technical 
basis would be valid, core or not. 

Cores happen to usually be the ones saying no most often, because they tend to 
have a broader/deeper understanding of the code base/architecture/direction. 
Correlation/causation fallacy at play, and the gist of the 
re-naming/re-structuring would be to make the structure less prone to that 
mis-perception.



> 
> 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

Reply via email to