Stopping ceph daemons during the upgrade

[Loic Dachary]

Hi,

To not confuse the ceph daemons during a package upgrade ( see http://tracker.ceph.com/issues/9153#note-13 for instance ), it would be better to stop the ceph daemons while ceph is being upgraded. Does that sound reasonable ?

Here is how it could be done for .deb packages : https://github.com/dachary/ceph/commit/cf3a0e7bef25e5190f3cdb69e57cb6b868d806fa and there probably is a way to do something similar with RPM packages.

Cheers

[Dan Van Der Ster]

Hi,

there probably is a way to do something similar with RPM packages.=20

That behaviour (well, close enough) just _removed_ from firefly, see:
https://github.com/ceph/ceph/commit/361c1f8554ce1fedfd0020cd306c41b0b=
a25f53e

I don=92t have a strong opinion if the pkg update should restart the da=
emon or not =97 but we should try not to change this too often as it ch=
anges our operating procedures.

Cheers, Dan--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Loic Dachary]

Hi Dan,

Pre-loading the erasure code plugins will reduce this race condition (i.e. the files will have to be modified between the start of the ceph-osd process and the bootstrap phase where it loads the plugins for it to happen) and it seems to be preferable to stopping the daemons. Thanks for giving an additional incentive to go in this direction !

Cheers

Hi,

Post by Loic Dachary
there probably is a way to do something similar with RPM packages.

https://github.com/ceph/ceph/commit/361c1f8554ce1fedfd0020cd306c41b0ba25f53e
I don’t have a strong opinion if the pkg update should restart the daemon or not — but we should try not to change this too often as it changes our operating procedures.
Cheers, Dan--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sage Weil]

Post by Loic Dachary
Hi Dan,
Pre-loading the erasure code plugins will reduce this race condition
(i.e. the files will have to be modified between the start of the
ceph-osd process and the bootstrap phase where it loads the plugins for
it to happen) and it seems to be preferable to stopping the daemons.
Thanks for giving an additional incentive to go in this direction !

BTW Loic, one other thing would could do is have a number or string in the
.so interface that we bump when the interface changes. Then loading the
plugin could fail with a friendly message instead of crashing.

sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Loic Dachary]

Good idea :-)

Post by Sage Weil

Post by Loic Dachary
Hi Dan,
Pre-loading the erasure code plugins will reduce this race condition
(i.e. the files will have to be modified between the start of the
ceph-osd process and the bootstrap phase where it loads the plugins for
it to happen) and it seems to be preferable to stopping the daemons.
Thanks for giving an additional incentive to go in this direction !

BTW Loic, one other thing would could do is have a number or string in the
.so interface that we bump when the interface changes. Then loading the
plugin could fail with a friendly message instead of crashing.
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html