Thanks for the detailed explanation, yes Agreed that it would create confusion when different components of same application runs with different versions.
Since I had tried 'slider update' command to update the configs and then to do complete app restart, thought there would be an option to do at component level as well. May be you might have provided 'update' command before getting 'upgrade' on board and now you have solved all binary as well as config upgrades using 'slider upgrade' command itself. Think this 'upgrade' command should be replacing 'update' command as well if I am not wrong. Or is there any specific use case which 'slider update' command solves? On Thu, Jun 11, 2015 at 1:55 AM, Gour Saha <[email protected]> wrote: > Upgrade of an application package should be visualized holistically. > > It could be as minor as a single config of a single component, OR as major > as changes to all the binaries and 10s/100s of additional new configs. > > If the original version was 1.0.0, then a single config update version > might be called 1.0.1, versus the major version update would probably be > called 2.0.0. > > It all boils down to how you as an app owner track any changes to your > application. But as long as there is a change, my guess is there is a > version change to your application as a whole. > > Managing mixed versions of different components of your application is a > challenge. > > Now coming back to your scenario - > > The newer version of your app config will pretty much be exactly the same > as v1.0 with only 1 config change for NIMBUS. Everything else remains the > same including the application binaries. > > So technically you do not need to call upgrade on components other than > NIMBUS. They can continue to run as is. But remember in the fault tolerant > world, containers are expected to fail without affecting your application > as a whole. So somewhere down the line if a SUPERVISOR container fails, > then a new container will take its place. It will show v1.0.1 although > technically nothing has changed for the SUPERVISOR (since these components > do not care about the new config property). > > If I have confused you more, then all it says is that we need Ambari to > automate this whole thing and make version management a breeze. > > -Gour > > On 6/10/15, 12:58 PM, "Chackravarthy Esakkimuthu" <[email protected]> > wrote: > > >Thanks for the response Gour, > > > >Since I was facing issue with packaging storm, I tried with hbase > >app-package and then identified that app_version reflects that. I tried > >reconfiguration using upgrade command as per the doc and it resulted in > >success. > > > >I understand that this upgrade will be really helpful in case of upgrading > >from one version to another version, but should I follow this same > >approach > >for updating the configuration of a particular component as well? > > > >Consider I need to just update one or more configuration specific for > >NIMBUS component, shouldn't be there a way to update the app_config.xml > >and > >restart that specific role/component instead of restarting all components? > >I would not want to restart supervisor processes in such cases. > > > >Thanks, > >Chackra > > > >On Wed, Jun 10, 2015 at 11:54 PM, Gour Saha <[email protected]> > wrote: > > > >> I think you are missing the app_version entry in your app_config file, > >> like this - > >> "site.global.app_version": "1.0", > >> > >> Please refer to this file as an example - > >> > >> > >> > https://github.com/apache/incubator-slider/blob/develop/app-packages/hbas > >>e/appConfig-default.json > >> > >> If that does not work, can you send me your modified app_config.xml (the > >> entire file) and also the complete cmd lines for "package --install" and > >> "create", so that I can look further into it? > >> > >> -Gour > >> > >> > >> On 6/8/15, 12:33 PM, "Chackravarthy Esakkimuthu" <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Gour, just tried with latest release 0.80.0 (slider client), but facing > >> some issues with 'versioning'. > >> > >> slider app package install done with "--version 1.0" and also modified > >>the > >> "application.def" in app_config.xml to include version in the path, > >> > >> Now cluster creation works and able to list all containers as well. > >>(even > >> with specific roles) > >> > >> But list command does not work with "version" option > >> > >> sudo -u yarn /usr/hdp/current/slider-client/bin/./slider list storm1 > >> --containers --version 1.0 > >> > >> > >> ContainerInfo object does not contain the AppVersion. > >> > >> > >> > >> Am I missing something like updating the configuration or jar in some > >> place? > >> > >> Changes I did as follows, > >> I updated Slider distribution in client machine and then just modified > >>the > >> "application.def" in app_config.xml. > >> > >> > >> On Mon, Jun 8, 2015 at 6:48 AM, Gour Saha <[email protected] > <mailto: > >> [email protected]>> wrote: > >> > >> Chackra, > >> If you are thinking of updating without doing a complete stop of your > >> application, you might want to look into rolling upgrade - > >> > >> > http://slider.incubator.apache.org/docs/slider_specs/application_pkg_upgr > >>ad > >> e.html > >> > >> > >> This feature is available from latest 0.80.0 release onwards. > >> > >> -Gour > >> > >> On 6/7/15, 4:16 AM, "Chackravarthy Esakkimuthu" <[email protected] > >> <mailto:[email protected]>> > >> wrote: > >> > >> >I am able to do complete cluster restart with modified configs, by > >>doing > >> >'slider update' , 'slider stop', 'slider start'. > >> > > >> >Suppose If I want to restart a particular component alone (say STORM > >> >SUPERVISOR) with the modified configs, how can I do it? Is there an > >>option > >> >to stop/restart a particular component? > >> > >> > >> > >> > >
