You are right that upgrade cmd supersedes the update cmd. upgrade is a formal way to do a zero-downtime upgrade of your application in production env and requires you to tag your app config with an appropriate app_version.
update cmd on the other hand requires a stop/start of your application. It is handy because you do not have to do stop, destroy and create all the time, just to make a config change. You just need to do stop, update and start. You are not forced to maintain an app_version property as well. Handy for dev/test env. -Gour On 6/10/15, 1:40 PM, "Chackravarthy Esakkimuthu" <[email protected]> wrote: >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? >> >> >> >> >> >> >> >> >> >>
