Open Stack

On Fri, Jul 12, 2013 at 1:57 AM, Robert Collins
<robertc at robertcollins.net>wrote:

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

can even keep this filter in the ironic repo instead of nova.


> Writing this it seems like the nova scheduler may be a tricky fit;
> perhaps we should - again- reevaluate just how this all glues
> together?
>
> -Rob
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130719/614a4725/attachment.html>