[dev][tc] Part 2: Evaluating projects in relation to OpenStack cloud vision

Ben Nemec openstack at nemebean.com
Mon Feb 11 21:03:36 UTC 2019



On 2/10/19 2:33 PM, Chris Dent wrote:
> 
> This a "part 2" or "other half" of evaluating OpenStack projects in
> relation to the technical vision. See the other threads [1][2] for
> more information.
> 
> In the conversations that led up to the creation of the vision
> document [3] one of the things we hoped was that the process could
> help identify ways in which existing projects could evolve to be
> better at what they do. This was couched in two ideas:
> 
> * Helping to make sure that OpenStack continuously improves, in the
>    right direction.
> * Helping to make sure that developers were working on projects that
>    leaned more towards interesting and educational than frustrating
>    and embarrassing, where choices about what to do and how to do it
>    were straightforward, easy to share with others, so
>    well-founded in agreed good practice that argument would be rare,
>    and so few that it was easy to decide.
> 
> Of course, to have a "right direction" you first have to have a
> direction, and thus the vision document and the idea of evaluating
> how aligned a project is with that.
> 
> The other half, then, is looking at the projects from a development
> standpoint and thinking about what aspects of the project are:
> 
> * Things (techniques, tools) the project contributors would encourage
>    others to try. Stuff that has worked out well.

Oslo documents some things that I think would fall under this category 
in http://specs.openstack.org/openstack/oslo-specs/#team-policies

The incubator one should probably get removed since it's no longer 
applicable, but otherwise I feel like we mostly still follow those 
policies and find them to be reasonable best practices. Some are very 
Oslo-specific and not useful to anyone else, of course, but others could 
be applied more broadly.

There's also 
http://specs.openstack.org/openstack/openstack-specs/specs/eventlet-best-practices.html 
although in the spirit of your next point I would be more +1 on the 
"don't use Eventlet" option for new projects. It might be nice to have a 
document that discusses preferred Eventlet alternatives for new 
projects. I know there are a few Eventlet-free projects out there that 
could probably provide feedback on their method.

> 
> * Things—given a clean slate, unlimited time and resources, the
>    benefit of hindsight and without the weight of legacy—the project
>    contributors would encourage others to not repeat.
> 
> And documenting those things so they can be carried forward in time
> some place other than people's heads, and new projects or
> refactorings of existing projects can start on a good foot.
> 
> A couple of examples:
> 
> * Whatever we might say about the implementation (in itself and how
>    it is used), the concept of a unified configuration file format,
>    via oslo_config, is probably considered a good choice, and we
>    should keep on doing that.

I'm a _little_ biased, but +1. Things like your env var driver or the 
drivers for moving secrets out of plaintext would be next to impossible 
if everyone were using a different configuration method.

> 
> * On the other hand, given hindsight and improvements in commonly
>    available tools, using a homegrown WSGI (non-)framework (unless
>    you are Swift) plus eventlet may not have been the way to go, yet
>    because it is what's still there in nova, it often gets copied.

And as I noted above, +1 to this too.

> 
> It's not clear at this point whether these sorts of things should be
> documented in projects, or somewhere more central. So perhaps we can
> just talk about it here in email and figure something out. I'll
> followup with some I have for placement, since that's the project
> I've given the most attention.
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.html 
> 
> [2] 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002524.html 
> 
> [3] https://governance.openstack.org/tc/reference/technical-vision.html
> 



More information about the openstack-discuss mailing list