Yeah, I agree k8s seems to have hit on a good model where interests are separately grouped from the code bases. This has allowed architecture to not to be too heavily influenced by the logical groups interest.
I'll go ahead and propose it again since its been a little while. In order to start breaking down the barriers between Projects and start working more towards integration, should the TC come up with an architecture group? Get folks from all the major projects involved in it and sharing common infrastructure. One possible pie in the sky goal of that group could be the following: k8s has many controllers. But they compile almost all of them into one service. the kube-apiserver. Architecturally they could break them out at any point, but so far they have been able to scale just fine without doing so. Having them combined has allowed much easier upgrade paths for users though. This has spurred adoption and contribution. Adding a new controller isn't a huge lift to an operator. they just upgrade to the newest version which has the new controller built in. Could the major components, nova-api, neutron-server, glance-apiserver, etc be built in a way to have 1 process for all of them, and combine the upgrade steps such that there is also, one db-sync for the entire constellation? The idea would be to take Constellations idea one step farther. That the Projects would deliver python libraries(and a binary for stand alone operation). Constilations would actually provide a code deliverable, not just reference architecture, combining the libraries together into a single usable entity. Operators most likely would consume the Constilations version rather then the individual Project versions. What do you think? Thanks, Kevin ________________________________________ From: Thierry Carrez [thie...@openstack.org] Sent: Tuesday, April 24, 2018 3:24 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [tc] campaign question: How can we make contributing to OpenStack easier? Fox, Kevin M wrote: > OpenStack has created artificial walls between the various Projects. It shows > up, for example, as holes in usability at a user level or extra difficulty > for operators juggling around so many projects. Users and for the most part, > Operators don't really care about project organization, or ptls, or cores or > such. OpenStack has made some progress this direction with stuff like the > unified cli. But OpenStack is not very unified. I've been giving this some thought (in the context of a presentation I was giving on hard lessons learned from 8 years of OpenStack). I think that organizing development around project teams and components was the best way to cope with the growth of OpenStack in 2011-1015 and get to a working set of components. However it's not the best organization to improve on the overall "product experience", or for a maintenance phase. While it can be confusing, I like the two-dimensional approach that Kubernetes followed (code ownership in one dimension, SIGs in the other). The introduction of SIGs in OpenStack, beyond providing a way to build closer feedback loops around specific topics, can help us tackle this "unified experience" problem you raised. The formation of the upgrades SIG, or the self-healing SIG is a sign that times change. Maybe we need to push in that direction even more aggressively and start thinking about de-emphasizing project teams themselves. -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
