My two cents: > I think if OpenStack wants to gain back some of the steam it had before, it > needs to adjust to the new world it is living in. This means: > * Consider abolishing the project walls. They are driving bad architecture > (not intentionally but as a side affect of structure)
As long as there is no walled garden, everything should be done in a modular way. I don't think having separated nova from cinder prevented some contributions, quite the contrary. (Optionally, watch [1]). I am not familiar with the modularity and ease of contribution in k8s, so the modularity could be there in a different form. [1]: https://www.youtube.com/watch?v=xYkh1sAu0UM > * focus on the commons first. Good point. > * simplify the architecture for ops: Good point, but I don't see how code, org structure, or project classification changes things here. > * come up with an architecture team for the whole, not the subsystem. The > whole thing needs to work well. Couldn't that be done with a group TC sponsored? > * encourage current OpenStack devs to test/deploy Kubernetes. It has some > very good ideas that OpenStack could benefit from. If you don't know what > they are, you can't adopt them. Good idea. > > And I know its hard to talk about, but consider just adopting k8s as the > commons and build on top of it. OpenStack's api's are good. The > implementations right now are very very heavy for ops. You could tie in K8s's > pod scheduler with vm stuff running in containers and get a vastly simpler > architecture for operators to deal with. Yes, this would be a major > disruptive change to OpenStack. But long term, I think it would make for a > much healthier OpenStack. Well, I know operators that wouldn't like k8s and openstack components on top. If you're talking about just a shim between k8s concepts and openstack apis, that sounds like a good project : p >> I've also argued in the past that all distro- or vendor-specific >> deployment tools (Fuel, Triple-O, etc [3]) should live outside of >> OpenStack because these projects are more products and the relentless >> drive of vendor product management (rightfully) pushes the scope of >> these applications to gobble up more and more feature space that may or >> may not have anything to do with the core OpenStack mission (and have >> more to do with those companies' product roadmap). > > I'm still sad that we've never managed to come up with a single way to > install OpenStack. The amount of duplicated effort expended on that > problem is mind-boggling. At least we tried though. Excluding those > projects from the community would have just meant giving up from the > beginning. Well, I think it's a blessing and a curse. Sometimes, I'd rather have only one tool, so that we all work on it, and not dilute the community into small groups. But when I started deploying OpenStack years ago, I was glad I could find a community way to deploy it using <company technology of choice>, and not <another new technology forced on me, not working with our current processes>. So for me, I am glad (what became) OpenStack-Ansible existed and I am glad it still exists. The effort your are talking about is not purely duplicated: - Example: whether openstack-ansible existed or not, people used to Ansible would still prefer deploying openstack with Ansible than with puppet or chef (because of their experience) if not relying on a vendor. In that case, they would probably create their own series of playbooks. (I've seen some). That's the real waste, IMO. - Deployments projects talk to each other. Talking about living outside OpenStack, where would, for you, OpenStack-Ansible, the puppet modules, or OpenStack-Chef be? For OSA, I consider our community now as NOT vendor specific, as many actors are now playing with it. We've spent a considerable effort in outreaching and ensuring everyone can get involved. So we should be in openstack/ right? But what about 4 years ago? Every project starts with a sponsor. I am not sure a classification (is it outside, is it inside openstack/?) matters in this case. > > I think Thierry's new map, that collects installer services in a > separate bucket (that may eventually come with a separate git namespace) > is a helpful way of communicating to users what's happening without > forcing those projects outside of the community. Side note: I'd be super happy if OpenStack-Ansible could be on that bucket! Cheers, JP (evrardjp) __________________________________________________________________________ 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
