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-pra... 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.h...
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002524....
[3] https://governance.openstack.org/tc/reference/technical-vision.html