[Pkg-opennebula-devel] Bug#675930: Bug#675930: Bug#675930: opennebula: Fails upgrade if suspended VMs are still there

[Olivier Berger]

Damien Raude-Morvan <drazzib at drazzib.com> writes:

> Olivier,
>
> On 04/06/2012 16:52, Olivier Berger wrote:
>> Damien Raude-Morvan <drazzib at drazzib.com> writes:
>>> I would expect that users would read upstream upgrade guide before 
>>> upgrading :
>>> http://opennebula.org/documentation:rel3.4:upgrade
>>>
>> 
>> I'm afraid this isn't a valid expectation for a Debian
>> maintainer.
>
> For a critical software like OpenNebula, I would expect user to at least
> (1) do a test upgrade before upgrade of controller node and (2) read
> upstream upgrade guide... but maybe I have too much expectation to
> debian users.
>

The problem is that once you started the apt upgrade, you get stuck, and
only chance to start over is to first reinstall the previous version
from snapshots, destroy VMs, upgrade, start over VM deployment, etc.

If an APT upgrade can't do everything, it shouldn't let the user stuck,
without a way back, and refuse the auto upgrade in the first place.

There are plenty of 'critical software' in Debian, for which auto
upgrades aren't possible, but which will help the user proceed to manual
changes at least.

Maybe there should be a versioning on the opennebula-node package that
prevents auto upgrades in case of such incompatibilities, like
opennebula-node-2.2, opennebula-node-3.2, opennebula-3.4, mutually
excluding themselves, forcing the admin to read the upgrade docs ? I've
seen something similar for postgres, where the DBs will beed to be
manually exported and imported in the next version IIRC.

>> At least, there should be a NEWS big red warning IMHO.
>
> I will had something to NEWS entry, but as you know it's not binding for
> users (someone who haven't apt-listchanges installed for instance).
>

Then I think there can be a preinst debconf template message in last
resort.

>>>    Before installing OpenNebula 3.4, make sure you don't have
>>>    any active VMs. Shutdown or delete all VMs.
>>>
>>> Ii will be difficult on the long run to keep maintaining all tricks to 
>>> keep package in sync with upstream handling...
>>>
>> 
>> That's the fate of the Debian maintainer : never pretended it would be
>> easy.
>> 
>> Anyway, for the problem at stake, I guess there could be some kind of a
>> check in a script that uses onevm list to check the status for instance
>> (or some lower level API I'm not aware of).
>
> Would you provide a patch ? :)
>

Nice one ;)

When I'm done with other stuff, who knows, but for the moment I still
have to spam^Wtest and report on FusionForge packaging in higher
priority.

Best regards,

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)