Open Stack

On Thu, Jul 10, 2014 at 01:32:16PM -0700, Devananda van der Veen wrote:
> On Wed, Jul 9, 2014 at 1:58 PM, Matthew Treinish <mtreinish at kortar.org>
> wrote:
> >
> > On Wed, Jul 09, 2014 at 10:58:27AM -0400, David Shrewsbury wrote:
> > > Hi!
> > >
> > > The ironic team is working on enabling the API tempest tests with
> ironic. However,
> > > ironic doesn???t yet completely support volume attachment, so the cinder
> api tests
> > > fail miserably (where attachment is needed).
> > >
> > > Proposed solutions are:
> > >
> > > 1) Disable cinder in devstack-gate when ironic is used.
> > >
> > > 2) Create a new ???attach_volume??? compute feature flag and check for it
> in the various
> > >     tempest tests (a grep for ???attach_volume??? in tempest shows several
> potentially
> > >     affected tests).
> > >
> > > It???s been suggested that since this is a feature listed in our
> hypervisor support
> > > matrix [1], then #2 might be the best option.
> > >
> > > Are there any preferences, or other suggestions, from the nova and QA
> folks?
> >
> > So I'm inclined to say go with #1 in this case. If you're not doing volume
> > attach then there is no reason to run cinder in the gate with tempest. We
> get
> > the cinder API test coverage on every other job and it's not like work on
> ironic
> > where it doesn't touch cinder is going to break things. I really don't
> see a
> > case where having both cinder and nova enabled but no volume attach is
> useful
> > with tempest, because that's basically the integration point between the 2
> > projects.
> 
> I would prefer option #2.
> 
> On the one hand, option #1 would make the test jobs run faster -- I
> selfishly think it would be nice to disable all services which Ironic does
> not use within our tests. That should include Trove, Swift, and Heat tests
> as well, and all the neutron feature tests we don't rely on. But what
> happens if we were to extend that practice to other services' d-g jobs? Is
> that good for OpenStack? No, probably not, because the gate's function is
> to ensure that projects work together, and so they should be tested
> together.
>
> I think it's reasonable to continue testing Cinder and Ironic in parallel,
> even if Ironic isn't *using* Cinder right now, to the degree that they can
> be tested side by side. What we actually want to skip is the Nova volume
> tests, and any Cinder scenario test which relies on attaching a volume to
> Nova, because Ironic has not implemented support for this. This is not an
> incompatibility which prevents running the volume service and the baremetal
> service in the same environment -- and certain users may still want to do
> that (eg, to run a mix of physical and virtual instances, and use cinder
> with the VMs).

So here's were it's actually different with Cinder. There are integration points
between all the other projects you cited (and all of the integrated ones I could
think of) although it's often not direct point of integration. For example:

- Swift gets used by glance which is being used to serve images to ironic
- Trove uses nova which uses ironic (same for sahara, heat, or anything booting
  a server)

The distinction with cinder is that if there is no attach support then there are
no integration points between ironic/nova and Cinder right now. What this means
is that there is absolutely no value in testing them together in an integrated
gate job. We get the cinder specific testing coverage from the other jobs. An
ironic change won't break because of cinder and vice versa. I might agree with
your above points if we didn't have cinder coverage everywhere else. The value
in testing things together is for co-gating and testing integration points. If
Ironic doesn't support volume attach then there is nothing to co-gate in the
ironic jobs.

You can also think of it this way: all that running with cinder enabled in the
ironic job which doesn't support volume attach will do is cause nondeterministic
failures completely unrelated to ironic to kick out ironic patches.

-Matt Treinish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/dffbcc62/attachment.pgp>