On 11/08/2016 12:13 PM, Matt Riedemann wrote:
I'd also like to say that I dislike the constant comparisons to the kernel. If people are going to make that comparison, then let's say the kernel overall is all of OpenStack, and there are subsystems, like nova/cinder/glance/etc, with their own subsystem maintainers, e.g. nova-core.
While there is some merit to that argument, it's not entirely accurate. Nova is roughly 1/45th the size of the whole kernel source, but the kernel has roughly 1600 separately-maintained subsystems. The "arch/x86" subdirectory in the kernel source is almost half as big as nova, but there are also separately-maintained drivers with only a few hundred lines of code.
Something that was mentioned in the summit discussion (but I think it bears repeating) is that the thing that enables this sort of fine-grained maintainership in the kernel is that the contracts are better-defined between the various subsystems. Generally a driver has a limited set of things that it needs to worry about getting right to interface with the rest of the system, and other than that it's got free rein in its own sandbox.
That said, I don't know that there's an easy solution to this in nova due to the fact that it's a distributed system with a central shared data store. Enhancing a sched filter might require new data, which means modifying the DB model and the DB migrations, and updating the InstanceNUMATopology object and tweaking nova-api to request additional attrs, and it might have implications for upgrade, etc.
Chris __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
