2018-04-25 0:04 GMT+08:00 Fox, Kevin M <[email protected]>: > > 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. >
I believe to combine API services into one service will be able to scale much easier. As we already starting from providing multiple services and binding with Apache(Also concern about Zane's comment), we can start this goal by saying providing unified API service architecture (or start with new oslo api service). If we reduce the difference between implementation from API service in each OpenStack services first, maybe will make it easier to manage or upgrade (since we unfied the package requirements) and even possible to accelerate APIs. > 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? > I like Zane's idea of combining services in Compute Node. > 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? It won't hurt when we providing unified OpenStack command (and it's actually a great stuff), and it should not break anything for API. Maybe just one more API service call OpenStack API service and it base on teams to said providing plugin or not. I think we will eventually reach the goal in this way. > > Thanks, > Kevin-- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
