fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

+ 1 to Evgeniy.
But we have to hide this complexity from the user and plugin developer as
much as we can.

On Tue, Oct 14, 2014 at 3:28 PM, Evgeniy L <eli@xxxxxxxxxxxx> wrote:

> Hi Roman,
>
> I see several problems with plugins replacement approach
>
>    - if we replace the old version, user can get inconsistent state when
>    new nodes are deployed with new version of plugin, but old nodes have
>    previous version, in this case we can use OpenStack patching approach and
>    if user performs any deployment action, we should run plugins update for
>    all of the nodes, I'm not sure if we should implicitly run plugins update
>    - each plugin has compatibility list with version of fuel and
>    OpenStack releases versions, new plugin can have removed compatibility with
>    old OpenStack releases, in this case we cannot run implicit update, because
>    plugin developer removed compatibility with old OpenStack releases, it
>    means that we need previous version of the plugin to manage old environments
>
> Thanks,
>
> On Tue, Oct 14, 2014 at 10:50 AM, Roman Alekseenkov <
> ralekseenkov@xxxxxxxxxxxx> wrote:
>
>> I think keeping multiple versions of the same plugin on master node can
>> be confusing.
>>
>> I'd vote for a simple approach:
>>
>>    - Allow replacing an old version of the plugin with a new version
>>    - Allow to re-run the plugin and let the plugin apply new changes
>>    - Hope that plugin developers made it idempotent, and also compatible
>>    with the previous versions of itself (i.e. plugin should not break the
>>    existing deployment that was produced with a previous version of the same
>>    plugin)
>>
>> Do you see any drawbacks of this approach?
>>
>> Thanks,
>> Roman
>>
>> On Fri, Oct 3, 2014 at 8:30 AM, Nikolay Markov <nmarkov@xxxxxxxxxxxx>
>> wrote:
>>
>>> I also think, that we shouldn't replace an old version of plugin with a
>>> new one, but in some cases (e.g. security fixes) this can be what customer
>>> needs.
>>>
>>> It is also possible to add an interface to select plugin version for
>>> particular environment, but in most cases new version may need re-executing
>>> action plugin is made for to apply new changes (this also mean that each
>>> new version of plugin should take into mind that previous could already
>>> been executed).
>>>
>>> So, I would suggest us to disable plugin upgrading on deployed
>>> environments for now and keep all versions simultaneously with an ability
>>> to select one for newly created environment.
>>> 03 Окт 2014 г. 19:15 пользователь "Evgeniy L" <eli@xxxxxxxxxxxx>
>>> написал:
>>>
>>> >
>>> > Hi guys,
>>> >
>>> > I would like to discuss with you a possibility to update Fuel plugins.
>>> > This topic was raised on one of our meetings.
>>> > I started the design of this part, and it turned to be pretty tricky.
>>> >
>>> > Let me describe you user's use case:
>>> > user installs master node
>>> > installs plugin with version 1.0
>>> > deploys env with enabled plugin
>>> > then there is new release from plugin developer with high priority
>>> fixes
>>> > user installs the plugins with version 1.1
>>> > On 5th step we can get interesting questions
>>> > should we replace the plugin or add second plugin with the different
>>> version?
>>> > how to update plugin on slaves?
>>> > Here I want to clarify a statement that single plugin can be
>>> compatible with
>>> > several versions of openstack, so, it should have scripts and packages
>>> > for each possible version of openstack which plugin developer wants
>>> > to support.
>>> >
>>> > 1st question.
>>> > We are not going to replace plugin, because new plugin can have
>>> different
>>> > openstack compatibility list.
>>> > It means that we have to keep and manage several versions of a single
>>> plugin
>>> > on the system.
>>> > It can work for the current release, e.g. for nailgun, but I'm not sure
>>> > if it would work for UI, Vitaly K. could you comment please?
>>> > Also when we create a cluster, there should be some drop-down to chose
>>> > specific version of plugin for new env.
>>> >
>>> > 2nd question.
>>> > I'm not sure if we will be able to implement "Plugin patching/update"
>>> > feature for the first release, because plugin developer writes his own
>>> > scripts for packages installation and cluster configuration, and I
>>> believe
>>> > not all of them will have `yum upgrade` for their packages.
>>> > Maybe we should provide ready interface, like, if you want your plugin
>>> > to be update friendly, put your special script in directory X.
>>> >
>>> > Thanks,
>>> >
>>> > --
>>> > Mailing list: https://launchpad.net/~fuel-dev
>>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~fuel-dev
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~fuel-dev
>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Mike Scherbakov
#mihgen