Open Stack

> 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.