Open Stack

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 <adidenko at mirantis.com>
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 <bdobrelia at mirantis.com>
> 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/5acccde9/attachment.html>