<div dir="ltr">Thank you for comments folks.<div>Clarifications, with the feedback incorporated:</div><div>1) We can install plugin developed against 8 to Fuel Mitaka (9). But it won't appear in the UI as available plugin. This is what I want to fix, and have just a warning that this plugin may not work.</div><div><br></div><div>2) To clarify, I'm talking about using plugin developed against 8.0-liberty in 9.0-mitaka, e.g. in newer Fuel with newer OpenStack release deployed. I understand that we've changed names of tasks, and now it's just impossible to have any meaningful plugin developed against 8 which would work in Mitaka without other task names, etc. But - do we expect renames over again and again? Any other changes? I hope the answer is no, that we want to stabilize an interface. I understand, that new OpenStack release may require changes in tasks, new tasks would appear, new dependencies. However, I assume that vast majority of components don't change that often. So, do we have any suggestions how we can keep tasks and whatever else from changes? Can we introduce backward compatibility here?<br>I'm trying to understand how hard it will be to make. As otherwise, every plugin developer will have to learn new tasks every new release, and re-do the work.</div><div><br></div><div>3) Multi-release support is kinda covered in (2) here. If plugin's code needs little tweaks in order to support new release of Fuel, I'd suggest to figure out how we can use inheritance and keep code for multiple Fuel releases in one plugin repo. In current reality, when it means to fork almost everything, I'm in a support of having a plugin branch per Fuel release. Thanks for links to the corresponding thread and plugins v5 spec, I'll take a careful look.</div><div><br></div><div>> <span style="line-height:1.5">So I don't quite understand how new</span><span style="line-height:1.5">"validated_against"</span><span style="line-height:1.5"> </span><span style="line-height:1.5">parameter will differ from existing "releases" list.</span></div><div><span style="line-height:1.5">Alex, I meant to have different use of what we have now. Instead of blocking a user from using a plugin in "unsupported" Fuel version, allow it - but warn.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Thanks,</span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 10, 2016 at 4:50 AM Aleksandr Didenko <<a href="mailto:adidenko@mirantis.com">adidenko@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>> Good idea. That should be done despite on any decision we will take.<br><br></div></div></div></div><div dir="ltr"><div><div>Currently you have to specify which releases your plugin supports [0]. So I can take my plugin developed for 8.0 and install it on Fuel-9.0 (I actually did it and it worked just fine). But I won't be able to enable this plugin for "mitaka-9.0" release because plugin was not developed and tested for it, so it does not have "miraka-9.0" in "releases" list [0]. So I don't quite understand how new <span style="line-height:1.5">"validated_against"</span><span></span> parameter will differ from existing "releases" list.<br><br></div>Regards,<br></div>Alex<br><br>[0] <a href="https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21" target="_blank">https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21</a><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 10.03.2016 08:30, Mike Scherbakov wrote:<br>
> Hi folks,<br>
> in order to make a decision whether we need to support example plugins,<br>
> and if actually need them [1], I'd suggest to discuss more common things<br>
> about plugins.<br>
><br>
> My thoughts:<br>
> 1) This is not good, that our plugins created for Fuel 8 won't even<br>
> install on Fuel 9. By default, we should assume that plugin will work at<br>
> newer version of Fuel. However, for proper user experience, I suggest to<br>
> create meta-field "validated_against", where plugin dev would provide<br>
> versions of Fuel this plugin has been tested with. Let's say, it was<br>
> tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest<br>
> to show a warning saying about risks and the fact that the plugin has<br>
> not been tested against 9. We should not restrict intsallation against<br>
> 9, though.<br>
<br>
</span>Good idea. That should be done despite on any decision we will take.<br>
<span><br>
><br>
> 2) We need to keep backward compatibility of pluggable interface for a<br>
> few releases. So that plugin developer can use pluggable interface of<br>
> version x, which was supported in Fuel 6.1. If we still support it, it<br>
> would mean (see next point) compatibility of this plugin with 6.1, 7.0,<br>
> 8.0, 9.0. If we want to deprecate pluggable interface version, we should<br>
> announce it, and basically follow standard process of deprecation.<br>
><br>
> 3) Plugin's ability to work against multiple releases of Fuel<br>
> (multi-release support). If if..else clauses to support multiple<br>
> releases are fairly minimal, let's say take less that 10% of LOC, I'd<br>
> suggest to have this supported. Just because it will be easier for<br>
> plugin devs to support their plugin code (no code duplication, single<br>
> repo for multiple releases).<br>
><br>
> Thoughts?<br>
><br>
> [1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html</a><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
><br>
><br>
</span><span>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
</span><span><font color="#888888">--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
</font></span><div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>