Open Stack

Hi Mike, thanks for clarification.

On Fri, Mar 11, 2016 at 9:42 AM, Mike Scherbakov <mscherbakov at mirantis.com>
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 <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
>
> __________________________________________________________________________
> 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/91a4b266/attachment.html>