I know huh...like a broken record :D
On Tue, Jul 30, 2013 at 1:50 PM, Jason Miller <jason.mil...@gmail.com>wrote: > ** Dude, I've already voted for MVP. Oh... :) > > On Tue, Jul 30, 2013 at 12:09 PM, Longwing, Lj <llongw...@usgs.gov> wrote: > >> ** >> And to make it SUPER easy >> https://communities.bmc.com/ideas/1421 >> that's the link to the idea...all you need to do is go in and log in (if >> not already) and click the up arrow to cast your vote...I really didn't >> expect this to be an issue...but apparently there isn't enough support to >> do various things in the community. >> >> Come on folks..participate :D >> >> >> On Tue, Jul 30, 2013 at 12:59 PM, Mueller, Doug <doug_muel...@bmc.com>wrote: >> >>> ** >>> >>> Tom (and others who responded),**** >>> >>> ** ** >>> >>> The "feature" of zero-down time and the demonstration at WWRUG 2012 was >>> a lab demo to show a**** >>> >>> concept that we had taken from design into prototype to gage interest >>> from the customer base.**** >>> >>> ** ** >>> >>> To be clear, it is not present in any release of the product at this >>> time.**** >>> >>> ** ** >>> >>> We are still gaging customer interest and I will say unfortunately, the >>> interest expressed in this topic has**** >>> >>> not been as strong as several of us expected. There is interest – don't >>> get me wrong – but there are other**** >>> >>> things that are generating much more concern from customers. There is >>> still a contingent struggling to get**** >>> >>> this capability added to an upcoming release – but nothing has made it >>> yet.**** >>> >>> ** ** >>> >>> ** ** >>> >>> The functionality we demonstrated was true zero-down time. It creates >>> parallel metadata tables with new**** >>> >>> and old definitions and different servers pointing to different sets – >>> ALL ON THE SAME DATA TABLES. Lots of**** >>> >>> work went in to handle deleted fields (delete is deferred because the >>> old version is still using the fields) and**** >>> >>> to even handle cases where archgid changes field IDs (extra view forms >>> are put in place so that both old and**** >>> >>> new use the IDs they expect and all is in place).**** >>> >>> ** ** >>> >>> Both old and new versions of the applications were available and running >>> through different servers in the**** >>> >>> server group so you could confirm that all was ready before you flipped >>> the switch.**** >>> >>> ** ** >>> >>> If any system went down, it came back up looking at its set of >>> definitions so everything is robust and**** >>> >>> recoverable while in this mixed mode.**** >>> >>> ** ** >>> >>> We went so far as to have servers running the old app have a signal to >>> load and prepare the new definitions**** >>> >>> in the background while continuing to run the old version so when they >>> were signaled to go live, they finished**** >>> >>> any current API call in the old version and any new API call started >>> working with the new version for absolute**** >>> >>> zero down time transition at the server.**** >>> >>> ** ** >>> >>> This means that any program or integration has zero interruption or >>> disruption.**** >>> >>> ** ** >>> >>> Now, the interactive user through the mid-tier has the issue of caching. >>> Depending on whether an immediate**** >>> >>> update occurs or you are just going to let the next interval check do >>> it, it may be instant to a few minutes**** >>> >>> before the updates are reflected to the client and there is going to be >>> a performance slowdown that will be**** >>> >>> noticeable as things are reloaded (kind of like a first time reload >>> after mid-tier startup) and then changed**** >>> >>> screens will show up. So, they are never down, but there is a short >>> time of affect on interaction of users.**** >>> >>> ** ** >>> >>> ** ** >>> >>> This is not fantasy as we have prototyped it and it was what was >>> demonstrated at WWRUG and it does work.**** >>> >>> ** ** >>> >>> If you have not entered your vote for this feature on the BMC >>> Communities AR System thread Ideas entry**** >>> >>> for this feature (this is an area where you or BMC posts enhancement >>> requests and the community can vote**** >>> >>> on it to show interest – higher vote totals help push features up the >>> list for implementation), please enter**** >>> >>> your vote to show support for the idea.**** >>> >>> ** ** >>> >>> ** ** >>> >>> This does not mean no work for the Administrator during an upgrade, but >>> it means no end user outage for**** >>> >>> an upgrade. It should also help reliability and success of an upgrade >>> in a dramatic way as you can test and**** >>> >>> verify and make any corrections in the new version before go live. It >>> also should remove the I have to do**** >>> >>> everything under time pressure in the middle of the night on a weekend >>> issue to avoid customer downtime**** >>> >>> as much as possible topic. So, a win for everyone all around.**** >>> >>> ** ** >>> >>> ** ** >>> >>> I hope this confirms and clarifies this capability, what it is and where >>> it is.**** >>> >>> ** ** >>> >>> Doug Mueller**** >>> >>> ** ** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> arslist@ARSLIST.ORG] *On Behalf Of *Tom Shurmur >>> *Sent:* Monday, July 15, 2013 6:57 PM >>> *To:* arslist@ARSLIST.ORG >>> *Subject:* 7.6.04 Upgrade to 8.1**** >>> >>> ** ** >>> >>> ** **** >>> >>> Howdy Listers,**** >>> >>> **** >>> >>> We are about to embark on upgrading from 7.6.04 to 8.1 on a windows >>> platform using MS-SQL. Has anyone used the No Downtime Upgrade method that >>> was presented at last year’s WWRUG to move from 7.6.04 to 8.1? If so, was >>> it smooth or bumpy ride?**** >>> >>> **** >>> >>> We will be standing up a test system with 2 app VMs and a DB to test >>> this approach.**** >>> >>> **** >>> >>> I look forward to your feedback**** >>> >>> **** >>> >>> Tom Shurmur**** >>> >>> Sr Remedy Developer**** >>> >>> Froedtert Health System**** >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_**** >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
