Yeah understood now, thanks for the clarification. On 11 Jun 2015 02:27, "Gour Saha" <[email protected]> wrote:
> 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? > >> >> > >> >> > >> >> > >> >> > >> > >> > >
