Open Stack

>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140411/ca958bea/attachment.html>