When a campaign enters the completed state, all new software has been installed changes to the information model has been done. In this state, SMF enables the PBE to persist the changes to the cluster information model.
In general terms, A campaign in completed state could be of value to the admin only if the pbe enabling also succeeded, otherwise if a cluster restart happened before pbe got enabled, the cluster will have to be recovered from backup! The patch updates the state of the campaign first and subsequently enables the PBE and the question from hans was whether to indefinitely retry on the IMM APIs when updating the campaign state or not! Mathi. ----- [email protected] wrote: > The question is: When is a campaign completed ? > > I would assume that *before* enabling PBE, the campaign has > checkpointed/backup'ed > its state to an imm.xml file and possibly other files being part of a > backup? > > I could be wrong here, but if I am not then in all senses of the word > the campaign has > been completed when that backup has been done. In fact you could argue > that it is > Completed even before that backup has been done, but aq cluster > restart before > Competed backup would result in the completed state being lost/rewound > to something earlier. > > IF the backup has completed and PBE is tgehn enabled, then even if you > get a cluster > restart before the PBE has managed to regenerate its file, the cluster > will come up > based on the imm.xml file. The only remaining issue is that it would > come up with PBE disabled. > > /AndersBj > > -----Original Message----- > From: Mathivanan Naickan Palanivelu [mailto:[email protected]] > > Sent: den 25 juni 2014 15:40 > To: Anders Björnerstedt > Cc: Hans Feldt; [email protected] > Subject: Re: [devel] [PATCH 1 of 1] smf: update campaign state before > restoring pbe in the completed state [#944] > > Hi Hans, > > SMF retries for about ~ 3.5 minutes on the IMM apis. > immutilWrapperProfile.nTries = 500; /* Times */ > immutilWrapperProfile.retryInterval = 400; /* MS */ > > > If PBE generation can take a long time, then i think the patch does > addresses the issue. i.e. the patch first updates the IMM about the > campaign state and subsequently enables the PBE. > > So, i thought there is no necessity to infinitely retry on the IMM > APIs except only if the IMM maintainers would suggest that an IMM API > call can be blocked for minutes (till ~ 3.5 minutes) at a stretch > (both during a pbe-enabled or disabled scenario)! > > Thanks, > Mathi. > > ----- [email protected] wrote: > > > Below it refers to "immutil waittime". > > I dont know exactly what that is but the default timeout in the imma > > > API is 10 seconds. > > > > So if tou here anticipate to get blocked by the PBE regenerating its > > > file, which is what happens when you enable the PBE, then that is a > > > way way too low a timeout. How long the PBE takes to generate the > file > > depends on the file system. But even for sync (the other blocker of > > > ccb writes) we say 60 seconds is the max allowed time. > > > > /AndersBj > > > > > > -----Original Message----- > > From: Hans Feldt [mailto:[email protected]] > > Sent: den 25 juni 2014 13:34 > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [devel] [PATCH 1 of 1] smf: update campaign state > before > > restoring pbe in the completed state [#944] > > > > Mathi, Ingvar is on vacation. > > > > We have our doubts about this patch. We would like to see SMF retry > > > setting the campaign state to COMPLETED until it succeeds. This > state > > change is a trigger for higher level SW management functionality. > With > > the proposed change in SMF the next level is also affected and needs > > > to cater for a non-writeable IMM. > > > > Is it possible for SMF to retry until it succeeds instead? > > > > Thanks, > > Hans > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] > > > Sent: den 24 juni 2014 03:16 > > > To: Ingvar Bergström > > > Cc: [email protected] > > > Subject: [devel] [PATCH 1 of 1] smf: update campaign state before > > > > restoring pbe in the completed state [#944] > > > > > > osaf/services/saf/smfsv/smfd/SmfCampState.cc | 7 ++++--- > > > 1 files changed, 4 insertions(+), 3 deletions(-) > > > > > > > > > By way of ticket #677 we restore the pbe in the campaign > completed > > state itself. > > > i.e. > > > In SmfCampStateExecuting::executeWrapup() > > > { > > > > > > a) we first restore the pbe > > > i.e. i_camp->restorePbe(); > > > > > > b) And, then subsequently update the campaign state, i.e. > > > changeState(i_camp, SmfCampStateExecCompleted::instance()); > > > > > > } > > > However, it is possible that when the pbe is restored, the pbe > could > > > > > take more time (than the immutil wait time) to become > functionally > > ready. And in such sitautions, the updation to the campaign state > will > > not succeed until the PBE is really ready. > > > The patch updates the campaign state first (to imm) inthe > completed > > > > > state and subsequently restores the pbe. > > > > > > diff --git a/osaf/services/saf/smfsv/smfd/SmfCampState.cc > > > b/osaf/services/saf/smfsv/smfd/SmfCampState.cc > > > --- a/osaf/services/saf/smfsv/smfd/SmfCampState.cc > > > +++ b/osaf/services/saf/smfsv/smfd/SmfCampState.cc > > > @@ -838,9 +838,6 @@ SmfCampStateExecuting::executeWrapup(Smf > > > return SMF_CAMP_FAILED; > > > } > > > > > > - //Activate IMM BPE if active when campaign was started. > > > - i_camp->restorePbe(); > > > - > > > // TODO Start wait to complete timer > > > LOG_NO("CAMP: Start wait to complete timer (not implemented > > yet)"); > > > > > > @@ -848,6 +845,10 @@ SmfCampStateExecuting::executeWrapup(Smf > > > changeState(i_camp, SmfCampStateExecCompleted::instance()); > > > > > > LOG_NO("CAMP: Upgrade campaign completed %s", > > > i_camp->getCampaignName().c_str()); > > > + > > > + //Activate IMM BPE if active when campaign was started. > > > + i_camp->restorePbe(); > > > + > > > TRACE_LEAVE(); > > > return SMF_CAMP_COMPLETED; > > > } > > > > > > > > > ---------------------------------------------------------------------- > > > -------- HPCC Systems Open Source Big Data Platform from > LexisNexis > > > > > Risk Solutions Find What Matters Most in Your Big Data with HPCC > > > Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty > Data. > > > Leverages Graph Analysis for Fast Processing & Easy Data > Exploration > > > > > http://p.sf.net/sfu/hpccsystems > > > _______________________________________________ > > > Opensaf-devel mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/opensaf-devel > > > > > ---------------------------------------------------------------------- > > -------- Open source business process management suite built on Java > > > and Eclipse Turn processes into business applications with Bonita > BPM > > Community Edition Quickly connect people, data, and systems into > > organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards > > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > Opensaf-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/opensaf-devel ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
