<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">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>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 28 October 2013 23:17, John Garbutt <<a href="mailto:john@johngarbutt.com">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 class="im"><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 class="HOEnZb"><div class="h5"><br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">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">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 class="gmail_default" 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>

<br></div></div>