How safe is a dist-upgrade from 7.8 to 8?
If you have a fairly vanilla 7.8 system (i.e. no source compiled stuff on there, mainly just big name packages etc.) then you should be fine doing it now or in a few days.
We updated some simple 7.8 installs to the rc jessie release a month or so ago and everything went fine apart from an obscure bug with monit and inherited umasks. Got around that by manually installing the sid deb of monit.
Edit: the main thing you'll want to do is go read up on systemd ahead of upgrading as it's quite a change and there are still some wrinkles ('systemctl daemon-reload' is a new command we've had to use quite a bit).
We've a lot of 7.x instances (bare metal and VMs both) and a few running jessie for about 2 months. The upgrade was flawless. systemd had quirks, but that faded too.
All in all, go ahead, it's yet again a nice little step forward.
Debian is generally very good with stability for things like security updates and we certainly plan to continue using it. However, our plans for updating this time are more along the lines of "set up completely new machine with Debian 8 from the start, install our own choice of packages and applications, and then systematically migrate data/connectivity from the old systems to the new ones". We expect the time and money costs of having the transition period to be less than the potential downtime if direct upgrades take as much effort as they did from 6 to 7.
Your mileage may vary, Linux has infinite possibilities and ours may just have been unlucky, the plural of anecdote is not data, etc.
Did your last upgrade issues stem from the upgrade procedure or were they because of new versions?
I can't remember all of the different problems now, but one I do remember is that if you had a typical set-up with mirrored (RAID1) drives but the boot-related partitions cloned rather than mirrored, one of the bootloaders got upgraded but not the other. That is, the drives were left out of sync and booting from one of the drives wouldn't work properly if the other failed. The thing that really concerned us wasn't so much the specific details here but that this was essentially a silent failure in the upgrade process, combined with a potentially catastrophic failure in a basic system function as a result.
I think there is quite a big difference between the theory of updating a couple of sources files and running a couple of upgrade commands and the practice of manually checking things like basic RAID configuration and reinstalling missing bootloader updates. This time around, the fact that Jessie uses systemd made the discussion for whether to even try a dist-upgrade a very short one, because literally everyone in the room agreed that the probability of failures was too high for that strategy to be worth considering. The substantial discussions were more about migration to fresh machines relatively soon vs. sticking with 7 at least until we know the LTS situation.
Did you use some tool to do that? How do you expect the upgrade process to even be able to take that kind of thing into account?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.
I've long forgotten exactly why these systems were first set up that way. Presumably it was because at the time someone was leaving their options open about the RAID set-up for the main drives/partitions and bootloaders of that generation didn't support MD well so keeping boot as a non-RAID set-up was not uncommon. Whatever the history, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.
How do you expect the upgrade process to even be able to take that kind of thing into account?
I don't think it's rocket science to suggest that if you're migrating to a new bootloader, and you've got a system with multiple drives in it (RAIDed or otherwise), and you're installing an OS that is widely used in server or multiple-OS environments, just assuming that you should upgrade the bootloader on one specific drive and ignore anything else is not a great idea. What if the sysadmin installing the update wasn't the person who installed the original and simply hadn't realised how the /boot was set up?
Without knowing any details it's hard to say if it was an actual bug or just plain old human error, but it sounds like the latter.
There was no "error". The situation before the upgrade was what it was, and after the upgrade the problem was quickly detected and fixed. But it took time and effort to do that, instead of having a smooth, fully automated upgrade process. Again, the fact is that before the automated part of the 6-to-7 upgrade there was a fully working system, and after it there wasn't.
Will the 7-to-8 update now expect everyone performing it to be intimately familiar with the implications of things like systemd? Because I'm betting plenty of people will encounter it for the first time as part of this upgrade cycle.
What about package compatibility? Some packages have been entirely removed in Jessie; see the political debates about FFmpeg vs. Libav for a relatively high-profile example. That is inevitably going to break some people's install scripts/tool recipes/etc.
My point here is that there are significant changes as part of the upgrade, and upgrades always carry a degree of risk, and my personal experience (based on several different projects) of the 6-to-7 upgrade process was that the risk was real and the fully automated part of the process was not able to do everything necessary itself. Consequently I would not recommend that anyone assume a 7-to-8 upgrade will necessary go completely smoothly and be fully automated either.
[Edit: To be clear, I'm not saying you shouldn't do it or something awful will happen. Nor am I criticising Debian for not anticipating every possible scenario and handling everything completely automatically. I'm just saying my experience last time around was different to kasabali's experience, and as one data point, projects I work on where the experience was not as smooth last time but the desire is to move to 8 quite quickly are generally favouring a clean install and application migration strategy rather than an in-place upgrade. The expectation of those teams is that this will incur less risk and might be faster anyway once you take all implementation and testing effort into account.]
Upgrade scripts certainly could try to predict every crazy thing people do with their computers, but past a certain point, it's not very productive. People are creative.
In the end, the admin must make the decision whether reinstalling and reconfiguring a server has a lower general cost than verifying and potentially fixing an upgraded installation.
If you did something unorthodox, such as building a boot process dependent on a manual step to clone drive, you surely must be prepared to deal with this in any number of situations that can arise?
All non-standard solutions carry a debt where all future admins must understand what you built and how this affects operation.
The point remains that this doesn't matter. Before the upgrade, there was a fully working system. After the automated part of the upgrade, there wasn't. The original question was how safe the upgrade from 7 to 8 is, and this is a demonstration of the fact that such upgrades can carry risk. I'm not saying don't do them, I'm not expecting Debian maintainers to be omniscient, and I'm not telling you your child isn't beautiful. I'm just saying if you're thinking about moving from 7 to 8, be aware of the potential that there will be things the automated tools can't or won't do for you that may break your system, and plan your upgrade or other migration strategy accordingly.
I'm not a DD and I have no vested interest in it, but that particular data point is an outlier no matter how you look at it.
There are more obvious situations where updates will break your system. Most common probably when you've installed third party packages with dependencies on system software. But that's not generally what's referred to when asked if the update process is stable. Such things will break no matter how stable the process in itself is.