Open Stack

> On Apr 1, 2015, at 7:19 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 
> On 04/01/2015 12:31 PM, Duncan Thomas wrote:
>> On 1 April 2015 at 10:04, Joshua Harlow <harlowja at outlook.com
>> <mailto:harlowja at outlook.com>> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev