<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 1:57 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 11 July 2013 02:39, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>


<br>
>> We'll probably need something like this for Ironic with persistent<br>
>> volumes on machines - yes its a rare case, but when it matters, it<br>
>> matters a great deal.<br>
><br>
> I believe you, but I guess I'd like to better understand how this works<br>
> to make sure what gets added actually solves your use case.  Is there<br>
> already support for Cinder managed persistent volumes that live on<br>
> baremetal nodes?<br>
<br>
</div>There isn't, but we discussed it with Cinder folk in Portland.<br>
<br>
Basic intent is this:<br>
 - we have a cinder 'Ironic' backend.<br>
 - volume requests for the Ironic backend are lazy provisioned: they<br>
just allocate a UUID on creation<br>
 - nova-bm/Ironic will store a volume <-> node mapping<br>
 - 'nova boot' without a volume spec will only select nodes with no<br>
volumes associated to them.<br>
 - 'nova boot' with a volume spec will find an existing node with<br>
those volumes mapped to it, or if none exists create the volume<br>
mapping just-in-time<br>
 - the deployment ramdisk would setup the volume on the hardware<br>
[using hardware RAID]<br>
   - where there isn't hardware RAID we'd let the instance take care<br>
of how to setup the persistent storage - because we don't have a<br>
translation layer in place we can't assume lvm or windows volume<br>
manager or veritas or.....<br>
<br>
The obvious gap between intent and implementation here is that choices<br>
about nodes happen in the nova scheduler, so we need the scheduler to<br>
be able to honour four cases:<br>
 - baremetal flavor with no volumes requested, gets a baremetal node<br>
with no volumes mapped<br>
 - baremetal flavor with volumes requested, just one baremetal node<br>
with any of those volumes exist -> that node<br>
 - baremetal flavor with volumes requested, > one baremetal node with<br>
any of those volumes exist -> error<br>
 - baremetal flavor with volumes requested, no nodes with any of those<br>
volumes -> pick any node that has enough disks to supply the volume<br>
definitions<br>
<br></blockquote><div><br></div><div>Wouldn't this all be possible today if we added a ironic nova filter?  Perhaps the current design wouldn't very performant though.  We </div><div><br></div><div>can even keep this filter in the ironic repo instead of nova.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Writing this it seems like the nova scheduler may be a tricky fit;<br>
perhaps we should - again- reevaluate just how this all glues<br>
together?<br>
<div class="im HOEnZb"><br>
-Rob<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Cloud Services<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<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><br></div></div>