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 <[email protected]> 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" <[email protected]> написал: > > > > > 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 : [email protected] > > Unsubscribe : https://launchpad.net/~fuel-dev > > More help : https://help.launchpad.net/ListHelp > > > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
