+ 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 <e...@mirantis.com> 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 < > ralekseen...@mirantis.com> 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 <nmar...@mirantis.com> >> 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" <e...@mirantis.com> >>> написал: >>> >>> > >>> > 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@lists.launchpad.net >>> > Unsubscribe : https://launchpad.net/~fuel-dev >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> >>> >>> -- >>> Mailing list: https://launchpad.net/~fuel-dev >>> Post to : fuel-dev@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~fuel-dev >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : fuel-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > > -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp