Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
On 11 March 2016 at 15:45:57, Simon Pasquier (spasqu...@mirantis.com) wrote: Thanks for kicking off the discussion! On Thu, Mar 10, 2016 at 8:30 AM, Mike Scherbakov 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. +1 Probably one of the most single important thing to have to be able to upgrade a deployed environment with a new plugin version! 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 __ 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
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
Thanks for kicking off the discussion! On Thu, Mar 10, 2016 at 8:30 AM, Mike Scherbakov 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
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
Hi Mike, thanks for clarification. On Fri, Mar 11, 2016 at 9:42 AM, Mike Scherbakov wrote: > Thank you for comments folks. > Clarifications, with the feedback incorporated: > 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. > > We can do that, but I don't think that we should add any new fields, we already have "releases" field, which specifies compatibility (hence they has to be verified with these versions). For versions which are not in the list, as you suggested, we can show a message for the user, that we don't actually know if it's going to work. > 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? > 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. > > As far as I know we have renames and graph shuffling (almost?) every release, but looking at some of the plugins, most of them use old format (i.e. pre/post), and for new tasks there are dependencies on anchors (pre/post) which don't get changed too often. I see no way (or I see only very expensive ways) to support graph in a way it won't break old plugins, even bug fix sometimes requires graph changes (e.g. to fix race conditions). > 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. > > > So I don't quite understand how new"validated_against" parameter will > differ from existing "releases" list. > 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. > > Thanks, > > > On Thu, Mar 10, 2016 at 4:50 AM Aleksandr Didenko > wrote: > >> > Good idea. That should be done despite on any decision we will take. >> >> 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 "validated_against" parameter will >> differ from existing "releases" list. >> >> Regards, >> Alex >> >> [0] >> https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21 >> >> >> On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya > > wrote: >> >>> On 10.03.2016 08:30, Mike Scherbakov 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. >>> >>> Good idea. That should be done despite on any decision we will take. >>> >>> > >>> > 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 >>> >
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
Thank you for comments folks. Clarifications, with the feedback incorporated: 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. 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? 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. 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. > So I don't quite understand how new"validated_against" parameter will differ from existing "releases" list. 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. Thanks, On Thu, Mar 10, 2016 at 4:50 AM Aleksandr Didenko wrote: > > Good idea. That should be done despite on any decision we will take. > > 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 "validated_against" parameter will > differ from existing "releases" list. > > Regards, > Alex > > [0] > https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21 > > > On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya > wrote: > >> On 10.03.2016 08:30, Mike Scherbakov 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. >> >> Good idea. That should be done despite on any decision we will take. >> >> > >> > 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-requ...@lists.openstack.org?subjec
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
> Good idea. That should be done despite on any decision we will take. 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 "validated_against" parameter will differ from existing "releases" list. Regards, Alex [0] https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21 On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya wrote: > On 10.03.2016 08:30, Mike Scherbakov 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. > > Good idea. That should be done despite on any decision we will take. > > > > > 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-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > 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
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
On 10.03.2016 08:30, Mike Scherbakov 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. Good idea. That should be done despite on any decision we will take. > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __ 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
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
Hi Mike, comments are inline. On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov 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. > User can install all previous version of plugins on Fuel 9, but those plugins are not going to be shown for Mitaka-9.0 release (for old release only). It should be added into compatibility list in order to make it compatible with OpenStack release. If you want to allow to enable plugin for specific release, it's going to be tricky since the format of DSL for different releases can be different, and you may get not only broken deployment, but 500 error from Nailgun since it will get unexpected format of data. > > 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. > It requires clarification, in fact we support backward compatibility for previous release, this requirement is a result of Fuel upgradability requirement (after upgrade to new Fuel plugins won't get broken for old releases). If we are talking about plugin format improvement/changes, then yes, we are thinking about deprecation, but it should be improved by sending announcement/writing document/providing appropriate messages during build. > 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). > > If you are referring to compatibility with master node, it's being supported. If it's about multi-release (OpenStack) support, it will take more time (and problems afterwards) to drop support of multi-release plugins. Hope that our tech debt will be fixed in the next release, since FFE was not granted for the current release [1]. Also we've had a huge discussion about it in a separate thread [2]. [1] https://review.openstack.org/#/c/271417/ [2] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086381.html 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
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
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 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-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
[openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
