Issues upgrading from 0.72.x (emperor) to 0.81.x (firefly)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,


I'm having a couple of issues during this update. On the test cluster
it went fine, but when running it on production I have a few issues.
(I guess there is some subtle difference I missed, I updated the test
one back when emperor came out).

For reference, I'm on ubuntu precise, I use self-built packages
(because I'm hitting bugs that are not fixed in the latest official
ones, but there is no change whatsoever to the debian/ directory
except the changelog and they're built with the dpkg-buildpackage). I
did a 'apt-get dist-upgrade' to upgrade everything despite the new
requirements.


* The first one is essentially the same as
http://permalink.gmane.org/gmane.comp.file-systems.ceph.devel/19632

dpkg: error processing
/var/cache/apt/archives/ceph-common_0.80.1-1we3_amd64.deb (--unpack):
 trying to overwrite '/etc/ceph/rbdmap', which is also in package ceph
0.80.1-1we3

apt complained about /etc/ceph/rbdmap being in two package and refused
to go further. I ended up using -o Dpkg::Options::="--force-overwrite"
 to force it to go on (because it just left some weird inconsistent
state and I needed to clean up the mess), but this seems wrong.


* The second one is that apparently it ran a "rm /etc/ceph" somehow
... on my setup this is not a directory, but a symlink to the real
place the config is stored (the root partition is considered
'expendable', so machine specific config is elsewhere). It also tried
to erase the /var/log/ceph but failed:

---
Replacing files in old package ceph-common ...
dpkg: warning: unable to delete old directory '/var/log/ceph':
Directory not empty
---


* And finally the upgraded monitor can't join the existing quorum.
Nowhere in the firefly update notes does it say that the new mon can't
join an old quorum. When this was the case back in dumpling, there was
a very explicit explanation but here it just doesn't join and spits
out "pipe fault" in the logs continuously.

Now it might be "normal", but being the production cluster, I can't
risk and upgrading more than half the mons if I'm not sure this is
indeed normal and not a symptom that the install/update failed and
that the mon is not actually working.



Cheers,

    Sylvain


[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux