(replies inline) On Wed, 18 Apr 2018, R. Tyler Croy wrote:
> > Howdy! I've been working this week to define the Jenkins Essentials > client<->server contracts for handling the _actual_ updates of Jenkins > Essentials. > > To help me organize my thoughts, I sketched out a quick draft of a JEP > yesterday afternoon which can be viewed here. > > https://github.com/jenkinsci/jep/pull/89 After a very helpful review by Olivier, his comment embedded below, I had a good hangout with Ba(p)tiste to determine a good way to handle the "disconnected client" problem. Olivier asked (https://github.com/jenkinsci/jep/pull/89#discussion_r182350032) Do you consider all updates as 'safe'? What happened if a client didn't connect to the update service for month? Is it an information that would be useful in the update manifest? Baptiste and I discussed what the right way to handle this is, and some of the thoughts I had swishing in the back of my brain bucket about utilizing "Update Levels" rather than tailoring an Update Manifest for each instance individually. Consider two instances, Alpha and Bravo. They both are created at the same time, at Update Level (UL) 1. Alpha stays online, and connected, for the next 14 days, while Bravo is disconnected until day 14. Our state is now: Alpha: UL14 Bravo: UL1 My first idea was to dry to have Bravo jump from UL1 -> UL14 but with Jenkins Essentials' testing process, this would effectively be a completely untested upgrade jump, and Baptiste and I considered it too risky. Another idea we discussed was using a git-bisect(1) type approach, trying UL14, if that fails, try UL7, and so on. We discarded this idea as well because it would be completely untested. What we ultimately decided was the right path forward was to use Update Levels (contrary to what the JEP presently describes), and staggar the upgrade logic for Bravo to where it can successfully go from UL1->UL2, then UL2->UL3, etc. Baptiste also raised the point of "What if we know that Update Level 5 is a bad update?" What we decided was that the backend services need the ability to mark a specific Update Level as tainted. SO in this example, once Bravo arrived at UL4, it would skip UL5, and upgrade to the untainted UL6. There are definitely some user experience concerns with downloading updates and restarting, but we decided that is something we're going to have to find a way to communicate to an end-user ("Why does Jenkins keep restarting?") and set up the update lifecycle to prefer stability and tested upgrade paths. I will be updating the JEP with this discussion shortly, thanks for the feedback thus far Olivier and Jesse! If you're interested in joining the Jenkins Essentials open planning meetings, we have our next on Monday April 23rd at 14:30 UTC (https://www.youtube.com/watch?v=SZK8fdGaVhk) Cheers -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20180420150305.GE1836%40grape.lasagna.io. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
