> I look at what we do with Ironic testing current as a guide here. > We have tempest job that runs against Nova, that validates changes > to nova don't break the separate Ironic git repo. So my thought > is that all our current tempest jobs would simply work in that > way. IOW changes to so called "nova common" would run jobs that > validate the change against all the virt driver git repos. I think > this kind of setup is pretty much mandatory for split repos to be > viable, because I don't want to see us loose testing coverage in > this proposed change.
Thanks Daniel for raising it this problem. Yeah I think that what we did with Ironic while the driver is* out of the Nova tree serves as a good example. I also think that having drivers out of the tree is possible, making the tests run against the "nova-common" and assert things didn't break is no problem. But as you described before the process of code submission was quite painful and required a lot of effort and coordination from the Ironic and Nova teams, we would need to improve that. Another problem we will have in splitting the drivers out is that classic limitation of launchpad blueprints, we can't track tasks across multiple projects. (This will change once Storyboard is completed I guess). But that's all a long-term solution. In the short term I don't have see any real solution yet, this thing about asking companies/projects that has a driver in Nova to help with reviews is not so bad IMO. I've started reviewing code in Nova today and will continue doing that, maybe aiming for core so that we can speed up the future reviews to the Ironic driver. Now, I let me throw a crazy idea here into the mix (it might be stupid, but): Maybe Nova is doing much more than it should, deprecating the baremetal and network part and splitting the scheduler out of the project helps a lot. But, and if other parts were splitted as well, like managing flavors, creating the instances etc... And then Nova can be the thing that knows how to talk/manage hypervisors only and won't have to deal with crazy cases like the Ironic where we try make real machines looks & feel like VMs to fit into Nova, because that's painful and I think we are going to have many limitations if we continue to do that (I believe the same may happen with the Docker driver). So if we have another project on top of Nova, Ironic and $CONTAINER_PROJECT_NAME** that abstract all the rest and only talks to Nova when a VM is going to be deployed or Ironic when a Baremetal machine is going to be deployed, etc... Maybe then Nova will be considerable small and can keep all drivers in tree (hypervisor drivers only, no Docker or Ironic). * was tempted to write 'was' there :) ** A new project that will know how to handle the containers case. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
