Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Patrick Petit]

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

[Simon Pasquier]

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

[Evgeniy L]

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

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Mike Scherbakov]

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

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

[Aleksandr Didenko]

> 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

[Bogdan Dobrelya]

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

[Evgeniy L]

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

[Matthew Mosesohn]

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