On 29 October 2013 04:20, Devananda van der Veen <devananda....@gmail.com> wrote: > On Mon, Oct 28, 2013 at 6:35 AM, John Griffith <john.griff...@solidfire.com> > wrote:
> I understand the desire to have something functional in nova-bm so you can > iron out the other parts of the TripleO story that will rely on local data > persisting through rebuild(). I think, as you pointed out, this would be > pretty easy to do within the current nova-bm code. I guess I don't > understand why using cinder volumes to act as the local non-ephemeral > storage with libvirt is not sufficient... Ah, because the short term TripleO will depend on the ephemeral contract - that is that the hypervisor formats the device and that cloud-init picks it up via nova metadata - via the block device mapping subtree. If we use Cinder in virt and ephemeral in physical, we now have a spurious testing difference that I'd like to avoid. Emulated BM nodes will obviously not have such a difference, but it is desirable to be able to test as much of the TripleO story as possible on top of regular instances, because we can scale the quantity of those /much/ more than either emulated BM nodes or physical nodes. > Whether you're testing nova-bm on real or emulated hardware, the rebuild > will be the same, and shouldn't use libvirt. The only reason I've thought of > (in the last few minutes) why you'd need to change libvirt is if you're > testing Heat and rebuild() without nova-bm, and you don't want divergent > code (cinder with libvirt || no cinder with nova-bm). It actually makes more > sense to me to test both code paths because the goal is to use cinder with > Ironic, and so I *wouldn't* want to change the way libvirt does this today > -- I would prefer to build the Ironic/Cinder/Nova-driver code to follow as > many of the same code paths as possible. So we should indeed test both code paths - once we have an Ironic Cinder story, that needs to also be tested at both layers, and for however long we support the [temporary] story with the ephemeral partition we'll want to keep testing it as well. > But you may have very different reasons that I'm overlooking, and I'm > interested to hear them. Nope, just testing layer consistency... though I say 'Just' and I mean 'this is super important for the ability to reason well about the significance of test pass/fail'. > Also, there will be a design session on Cinder for Ironic local storage: > http://summit.openstack.org/cfp/details/350 Cool. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
