fuel-dev team mailing list archive

[Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>]

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