Thanks for kicking off the discussion! On Thu, Mar 10, 2016 at 8:30 AM, Mike Scherbakov <mscherba...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
