fuel-dev team mailing list archive

[Evgeniy L <eli@xxxxxxxxxxxx>]

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