Hello,
This is a new version of my ZFS's LUN management code refactor, this time
completely
removing 'embedded' LunCmd drivers, and adding them as independent perl scripts
to pve-storage repo.
ZFSPlugin functionality has been tested and it works fine with our one
zfs-helper,
also, I've tried to
> The idea was to have a forward compatible upgrade path for existing users.
> And current users only had the option of running LUN code on proxmox
> servers. So it did not sound as a bad thing to keep this constraint if this
> allowed having a smaller/simpler script.
Oh, I see what you what to d
The idea was to have a forward compatible upgrade path for existing users. And
current users only had the option of running LUN code on proxmox servers. So it
did not sound as a bad thing to keep this constraint if this allowed having a
smaller/simpler script.
Sent from my iPhone
> On 20 Mar 2
On Thu, 20 Mar 2014 16:32:44 +0100
Pablo Ruiz wrote:
>
> Any preferences on this subject?
>
If your scripts should be able to execute on non-proxmox servers then
the answer is obvious.
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://pgp.mit.edu:113
> 2) Duplicate the required functions into each of the scripts, so the scripts
> are
> autonomous & independent and can be run on hosts not having proxmox's
> perl packages, etc.
>
> Any preferences on this subject?
what functions are used (run_command?), maybe you can simply use system()
inste
Another question regarding this lun scripts.. I will be adding them, as
requested, into a new dir /scripts at pve-storage repo.
However, the actual lun helpers (ie LunCmd/*) make use of (among others)
PVE::Tools package's functions, and I am facing two options:
1) Import such packages into each o
> 1) As I have no access to some of the software/hardware required to tests all
> of the currently implemented iSCSI targets, I would need some colaboration
> from existing users willing to tests the new code. Volunters?
Maybe Michael (mir) can do that?
> 2) Where should I include such scripts? M
Hi,
I am now working on this change, and regarding existing LUN drivers, I
would like to try to create some drivers from the existing perl code. My
idea would be creating an independent & standalone 'driver.pl' for each
existing driver, which can be placed somewhere on your proxmox (or zfs)
server
Daniel, That's exctly the idea. ;)
I'll be a bit busy this week attending some conferences, etc. But I will
work on a revised patch the next week so it can be reviewed by any
interested peers on this same list.
Regards
Pablo
On Sun, Mar 2, 2014 at 9:08 PM, Daniel Hunsaker wrote:
> > I might ha
> I might have misunderstand what you are trying to do.
If I've followed this correctly, it's basically set it up to call a script
instead of implementing things internally, and each storage entry (in
storage.cfg) defines which script to call. So you have scripts for each
LUN implementation you u
On Sun, 2 Mar 2014 07:50:09 +
Dietmar Maurer wrote:
>
> Why do you want a single script? We can have multiple scripts, one for each
> server type.
>
I might have misunderstand what you are trying to do.
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
> > > I have no objections. Only a cause of warning: Depending on the
> > > implementation of the script which will now govern all the reel LUN
> > > handling this could lead to a complex and messy
> >
> > Why is that different than the current LUN plugin?
> >
> Merge it all into one single script
On Sat, 1 Mar 2014 13:13:00 +
Dietmar Maurer wrote:
> > I have no objections. Only a cause of warning: Depending on the
> > implementation of the script which will now govern all the reel LUN
> > handling this could lead to a complex and messy
>
> Why is that different than the current LUN
> I have no objections. Only a cause of warning: Depending on the
> implementation of the script which will now govern all the reel LUN
> handling this could lead to a complex and messy
Why is that different than the current LUN plugin?
___
pve-devel m
On Fri, 28 Feb 2014 07:44:31 +
Dietmar Maurer wrote:
>
> Yes, correct.
>
> Any objections from mir or alexandre?
>
I have no objections. Only a cause of warning: Depending on the
implementation of the script which will now govern all the reel LUN
handling this could lead to a complex and m
> If I understand it correctly, what you mean is removing all LunCmd
> implementations and just invoke a remote script (defined at storage.cfg)
> from the ZFS plugin directly.
exactly
> That would be great and would still allow each
> implementor of a ZFS backend to freely implement their own LU
Yeah!
If I understand it correctly, what you mean is removing all LunCmd
implementations and just invoke a remote script (defined at storage.cfg)
from the ZFS plugin directly. That would be great and would still allow
each implementor of a ZFS backend to freely implement their own LUN
management l
> Please let me know where to move forward with this change and I will be
> after it right away.
OK, I think I have a better idea now. What if we simply use a script to
implement LUN commands
on the server side? That way we have a well-defined API, and can remove the
whole LUN plugin
code from o
Hi Dietmar,
What I am using is a customized redhat cluster setup with ZFS on linux,
plus some resource agent & helper scripts (available here:
https://github.com/pruiz/zfs-cluster) which allow management of NFS/iSCSI
exports, along with raking care of mounting/unmounting (export/import in
ZFS term
> I am going to deep into dynamic loading of lun plugins and wil be seinding a
> new version of the code ASAP.
I would still prefer if you simply use the current framework and simply send
patches for your new
ZFS LUN plugin. That way everybody can see what you are working on, and we can
also
he
> This is an interesting idea, however in such a case, my main issue would be
> validating new store.cfg parameters each new plugin would need/add. As
> json schema validation needs to be done before store.cfg' contents are
> loaded and thus we would have not loaded the plugins either.
A LUN plugi
Hi Dietmar,
I am going to deep into dynamic loading of lun plugins and wil be seinding
a new version of the code ASAP. However, would you consider merging the
second patch ([PATCH 2/2] Improve parsing of zfs volumes (ZVOLs) in order
to avoid) which indeed is not related to the lun plugins?
Regard
This is an interesting idea, however in such a case, my main issue would be
validating new store.cfg parameters each new plugin would need/add. As json
schema validation needs to be done before store.cfg' contents are loaded
and thus we would have not loaded the plugins either.
Any ideas?
On Wed
> 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
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
> 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 ind
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
Hello,
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 ind
28 matches
Mail list logo
