> > > Any disagreements with that goal? > No disagreement at all.
Not that we're talking yet about moving the driver back into Nova, I'd like to take this opportunity to remind anyone interesting in contributing a Cinder driver that it would be a lot easier if they do it while the driver is still in Stackforge. > Correct. If this is intended for infra, it has to use > devstack-gate. That has lots of levers that we need to set based on > branches, how to do the zuul ref calculations (needed for the > speculative gating), how to do branch overrides for stable an > upgrade jobs, etc. I suppose I wasn't very clear and what I said may have been misinterpreted. I'm certainly not opposed to the integration being introduced into devstack-gate or testing that way. I'm also happy that someone wants to contribute on the '-infra' side of things (thank you Derek!). In part, my response earlier was to point to work that has already been done, since Derek pointedly asked me about those efforts. Derek: for more clarification on the Tempest work, however, most of the patches necessary for using Docker with Tempest have been merged into Tempest itself. Some patches were rejected or expired. I can share these with you. Primarily, these patches were to make tempest work with Cinder, Neutron, suspend/unsuspend, pause/resume, and snapshots disabled. Snapshot support exists in the driver, but has an open bug that prevents tempest from passing. Neutron support is now integrated into the driver. Primarily, the driver lacks support for suspend/unsuspend and pause/resume. As for dockenstack, this might deserve a separate thread. What I've done here is build something that may be useful to openstack-infra and might necessitate further discussion. It's the fastest way to get the Docker driver up and running, but that's aside to its more generic usefulness as a potential tool for openstack-infra. Basically, I do not see dockenstack as being in conflict with devstack-gate. If anything, it overlaps more with 'install_jenkins_slave.sh'. What's nice about dockenstack is that improving that infrastructure can be easily tested locally and as the jobs are significantly less dependent on that infrastructure, those jobs may be easily run on a developer's workstation. Have you noticed that jobs in the gate run significantly faster than devstack on a laptop? Does that have to be the case? Can we not consolidate these into a single solution that is always fast for everyone, all the time? Something used in dev and gating? Something that might reduce the costs for running openstack-infra? That's what dockenstack is. -- Regards, Eric Windisch
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
