<div dir="ltr">On Wed, Jul 9, 2014 at 1:58 PM, Matthew Treinish <<a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a>> wrote:<br>><br>> On Wed, Jul 09, 2014 at 10:58:27AM -0400, David Shrewsbury wrote:<br>
> > Hi!<br>> ><br>> > The ironic team is working on enabling the API tempest tests with ironic. However,<br>> > ironic doesn’t yet completely support volume attachment, so the cinder api tests<br>
> > fail miserably (where attachment is needed).<br>
> ><br>> > Proposed solutions are:<br>> ><br>> > 1) Disable cinder in devstack-gate when ironic is used.<br>> ><br>> > 2) Create a new “attach_volume” compute feature flag and check for it in the various<br>
> > tempest tests (a grep for “attach_volume” in tempest shows several potentially<br>> > affected tests).<br>> ><br>> > It’s been suggested that since this is a feature listed in our hypervisor support<br>
> > matrix [1], then #2 might be the best option.<br>> ><br>> > Are there any preferences, or other suggestions, from the nova and QA folks?<br>><br>> So I'm inclined to say go with #1 in this case. If you're not doing volume<br>
> attach then there is no reason to run cinder in the gate with tempest. We get<br>> the cinder API test coverage on every other job and it's not like work on ironic<br>> where it doesn't touch cinder is going to break things. I really don't see a<br>
> case where having both cinder and nova enabled but no volume attach is useful<br>> with tempest, because that's basically the integration point between the 2<br>> projects.<div><br></div><div><div>I would prefer option #2.</div>
</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>-Devananda</div><div><br>><br>> The only downside to doing number 1 is that there will be a chicken and egg<br>> problem when you go to finish the ironic cinder support. But, that's easily<br>
> solved with a throwaway patch which will run with the ironic cinder support<br>> patch and the tests with cinder enabled.<br>><br><div><br></div></div></div>