Open Stack

Hi Mike,

Normally I would support your idea, but the reality is any plugin from
7.0 that defines a plugin role isn't going to work in 8.0 or 9.0. We
changed too many task names and you just can't make a plugin support
both versions.... not without something incredibly clever that I
haven't thought of already. If I'm a plugin developer, I'm not going
to advertise support for versions that won't work.... or expect it to
work when I haven't stated it explicitly.

The example plugins are quite simple and have no real tasks, so
enabling this for plugins is ok.  For real plugins that do more then
install 1 package and enable 1 service, version limiting is the only
thing to keep your users from losing their hair trying to figure out
why it doesn't work.

Best Regards,
Matthew Mosesohn

On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov
<mscherbakov at mirantis.com> wrote:
> Hi folks,
> in order to make a decision whether we need to support example plugins, and
> if actually need them [1], I'd suggest to discuss more common things about
> plugins.
>
> My thoughts:
> 1) This is not good, that our plugins created for Fuel 8 won't even install
> on Fuel 9. By default, we should assume that plugin will work at newer
> version of Fuel. However, for proper user experience, I suggest to create
> meta-field "validated_against", where plugin dev would provide versions of
> Fuel this plugin has been tested with. Let's say, it was tested against 7.0,
> 8.0. If user installs plugin in Fuel 9, I'd suggest to show a warning saying
> about risks and the fact that the plugin has not been tested against 9. We
> should not restrict intsallation against 9, though.
>
> 2) We need to keep backward compatibility of pluggable interface for a few
> releases. So that plugin developer can use pluggable interface of version x,
> which was supported in Fuel 6.1. If we still support it, it would mean (see
> next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If we want
> to deprecate pluggable interface version, we should announce it, and
> basically follow standard process of deprecation.
>
> 3) Plugin's ability to work against multiple releases of Fuel (multi-release
> support). If if..else clauses to support multiple releases are fairly
> minimal, let's say take less that 10% of LOC, I'd suggest to have this
> supported. Just because it will be easier for plugin devs to support their
> plugin code (no code duplication, single repo for multiple releases).
>
> Thoughts?
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html
> --
> Mike Scherbakov
> #mihgen
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>