<div dir="ltr"><div>On Mon, Oct 28, 2013 at 6:35 AM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:'courier new',monospace">
<br></div><div class="gmail_extra"><div><div class="h5">On Mon, Oct 28, 2013 at 4:49 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On 28 October 2013 23:17, John Garbutt <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>> wrote:<br>
> Is there a reason why you could not just use a Cinder Volume for your<br>
> data, in this case?<br>
<br>
</div>Because this is at the baremetal layer; we want local disks - e.g.<br>
some of the stuff we might put in that partition would be cinder lvm<br>
volumes for serving out to VM guests. Until we have a cinder<br>
implementation that can reference the disks in the same baremetal node<br>
an instance is being deployed to we can't use Cinder. We want that<br>
implementation, and since it involves nontrivial changes as well as<br>
cross-service interactions we don't want to do it in nova-baremetal -<br>
doing it in Ironic is the right place. But, we also don't want to<br>
block all progress on TripleO until we get that done in Ironic....<br>
<div><br>
> While at a first glance, it feels rather wrong, and un-cloudy, I do<br>
> see something useful about refreshing the base disk, and leaving the<br>
> data disks alone. Prehaps it's something that could be described in<br>
> the block device mapping, where you have a "local volume" that you<br>
> choose to be non-ephemeral, except for server terminate, or something<br>
> like that?<br>
<br>
</div>Yeah. Except I'd like to just use ephemeral for that, since it meets<br>
all of the criteria already, except that it's detached and recreated<br>
on rebuild. This isn't a deep opinion though - mainly I don't want to<br>
invest a bunch of time building something needlessly different to the<br>
existing facility, which cloud-init and other tools already know how<br>
to locate and use.<br>
<br>
-Rob<br>
<div><div><br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com" target="_blank">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div></div><div style="font-family:'courier new',monospace">Personally I'd rather go the proper route and try to get what you need in to Cinder, FWIW the local storage provisioning is something that Vish brought up last summit but nobody picked it up. I'd like to make that happen early in I. I'm not familiar with the work-around your proposing though so maybe it's not an issue, just hate to put in a temporary hack that will end up likely taking on a life of its own once it lands.</div>
</div></div></blockquote></div><br></div><div class="gmail_extra"><div><br class="">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... </div>
<div><br></div><div>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.</div>
<div><br></div><div>But you may have very different reasons that I'm overlooking, and I'm interested to hear them.</div><div><br></div><div>Also, there will be a design session on Cinder for Ironic local storage:<br>
</div><div><div> <a href="http://summit.openstack.org/cfp/details/350">http://summit.openstack.org/cfp/details/350</a></div><div><br></div></div><div><br></div><div>-Deva</div><div class="gmail_extra"><br></div></div></div>