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 <[email protected]> > 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
pgpJaJpFfNjqB.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
