Open Stack

Thanks for kicking off the discussion!

On Thu, Mar 10, 2016 at 8: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.
>

>From a plugin developer's standpoint, this point doesn't worry me too much.
It's fairly easy to hack the metadata.yaml file for supporting a newer
release of Fuel and I suspect that some users already do this.
And I think that it is good that plugin developers explicitly advertise
which Fuel versions the plugin supports.
That being said, I get the need to have something more automatic for CI and
QA purposes. What about having some kind of flag/option (in the Nailgun
API?) that would allow the installation of a plugin even if it is marked as
not compatible with the current release?



>
> 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.
>

+1 and more.
>From my past experience, this is a major issue that complicates the plugin
maintenance. I understand that it is sometimes necessary to make breaking
changes but at least it should be advertised in advance and to a wide
audience. Not all plugin developers monitor the Fuel reviews to track these
changes...


>
> 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).
>

>From my experience (and assuming that framework compatibility isn't
broken), this is usually what happens. You need a few if clauses to deal
with the differences between releases N and N+1 but this is manageable.


>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/b87836cf/attachment.html>