Open Stack

On Tue, 8 Nov 2016, Chris Friesen wrote:

> That said, I don't know that there's an easy solution to this in nova due to 
> the fact that it's a distributed system with a central shared data store. 
> Enhancing a sched filter might require new data, which means modifying the DB 
> model and the DB migrations, and updating the InstanceNUMATopology object and 
> tweaking nova-api to request additional attrs, and it might have implications 
> for upgrade, etc.

The symptoms that you are describing here are pretty much the crux
of the biscuit.

As much as I think having additional cores or subsystem maintainers
with +2 but not +W would probably be useful, I don't think it will
do much to fix the fundamental problem -- the crux above -- so the
concerns that people have about the risks will continue, will continue
to be valid and can't just be dismissed.

That's a technology crux. There's also a social crux.

It was very clear in BCN that there is significant disagreement in
the community over the volume of code that nova ought to be accepting.
Even in an ideal world where a lot of the roadblocks that people are
experiencing aren't there, there would be disagreement between at least
two (idealized, not literal) camps: One that says any code which doesn't
break stuff and is vaguely in the domain of what nova is about should be
merged and another that says nova should have a clear and focused
vision and contributions that don't fit that vision should be rejected.

At the moment both of these cruxes seem to be treated as things that
are too hard to change, or at least too hard discuss.

On the tech crux some people claim that the decomposition (and the
related boundary hardening) that would lead to safe contracts between
subsystems have already gone as far as they can or taking them
further requires such a huge amount of effort that given resources
and other commitments it can't happen. That smacks of a lack of
imagination and hope.

On the social crux, the impression I got is that people are either
too exhausted, too busy, too angry, or too scared to actually talk
things out and reach a conclusion and instead bitch behind each other's
backs about the lack of agreement and some other core who will either
reject or accept code they shouldn't be. We need to be honest about
this lack of trust if we want to make it better. And we need resolve
the vision of the project, in a concrete fashion.

Until at least one of those cruxes is resolved it's going to be
really hard to make substantial progress and many of the strategies
we try are going to be tactical band-aids.

mdbooth's proposal is somewhat different from some of the other
options because implementing it requires a leap of faith over
both cruxes into what could be a self-reinforcing environment: we will
trust one another because we've said we will, and we will build the
stronger contracts because we need them in order to be able to trust
people, and we will talk about it all (better than we do now) because it
won't work if we don't.

That might work. It could be a mess, but it is better than an
alternative which is feeling increasingly likely: People go elsewhere.

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)        https://anticdent.org/
freenode: cdent                                         tw: @anticdent