<div dir="ltr">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.<div>

<br></div><div>Any ideas?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 7:35 AM, Dietmar Maurer <span dir="ltr"><<a href="mailto:dietmar@proxmox.com" target="_blank">dietmar@proxmox.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> This is just an additional plugin under LunCmd which allows developing lun<br>
> plugins without depending on proxmox's release schedle. And which canbe<br>
> used in cases where the plugin to be developed is going to be too specific to<br>
> be usefull for others.<br>
> The way I see it, ending up with a lot of specific lun plugins into proxmox's<br>
> code base would entail a lot of overhead, specially when it comes to add<br>
> features or improve the zfs plugin, as you have to dig into one and each of<br>
> the lun plugins behind the zfs plugin. Something not ease, as not every<br>
> developer have access to every kind of lun system.<br>
> Having a generic lun plugin like the one I am proposing allows third parties to<br>
> develop their own lun driver without imposing an extra overhead on<br>
> proxomox (as a company) nor on proxomox's developers/community. But it<br>
> also allows developing and improving such drivers independently of<br>
> proxmox's release schedule. (Ie. Not having to wait for the next release to<br>
> incorporate new fixes into the lun management code).<br>
<br>
</div>I think you should improve the current plugin code to dynamically load/find new<br>
plugins. That way you will have all above advantages, without defining a<br>
"plugin inside a plugin" infrastructure.<br>
<br>
<br>
</blockquote></div><br></div>