[pve-devel] New Feature: ZFS 'generic' support for LUN management.

[Pablo Ruiz]

This is just an additional plugin under LunCmd which allows developing lun
plugins without depending on proxmox's release schedle. And which canbe
used in cases where the plugin to be developed is going to be too specific
to be usefull for others.

The way I see it, ending up with a lot of specific lun plugins into
proxmox's code base would entail a lot of overhead, specially when it comes
to add features or improve the zfs plugin, as you have to dig into one and
each of the lun plugins behind the zfs plugin. Something not ease, as not
every developer have access to every kind of lun system.

Having a generic lun plugin like the one I am proposing allows third
parties to develop their own lun driver without imposing an extra overhead
on proxomox (as a company) nor on proxomox's developers/community. But it
also allows developing and improving such drivers independently of
proxmox's release schedule. (Ie. Not having to wait for the next release to
incorporate new fixes into the lun management code).
On Feb 24, 2014 7:10 AM, "Dietmar Maurer" <dietmar at proxmox.com> wrote:

> > Our iSCSI/ZFS infraestructure is somewhat specific to our environment,
> and I
> > felt like adding a driver just for us was of no use for proxmox folks,
> nor for
> > the community at large, so I've opted for an alternative way by
> introducing a
> > 'generic' LUN management driver which just invokes an independent
> > 'management helper' (which can be either an script or a native binary)
> which
> > is invoked for lun creation/deletion/etc.
> >
> > This way, the specifics of the lun management can be developed
> > independently of proxmox, and we can avoid interfering with proxmox's
> > release schedule.
>
> We already have a plugin design for LUN management (PVE/Storage/LunCmd/).
> Why do you want to invent something new?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20140224/80a98abe/attachment.htm>