On Fri, Jul 12, 2013 at 1:57 AM, Robert Collins <robe...@robertcollins.net>wrote:
> On 11 July 2013 02:39, Russell Bryant <rbry...@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 <rbtcoll...@hp.com> > Distinguished Technologist > HP Cloud Services > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
