Bug 1499098
Summary: | Upgrading the ceph-selinux package unconditionally restarts all running daemons if selinux is enabled and context has changed | ||
---|---|---|---|
Product: | [Red Hat Storage] Red Hat Ceph Storage | Reporter: | Brad Hubbard <bhubbard> |
Component: | Documentation | Assignee: | Erin Donnelly <edonnell> |
Status: | CLOSED NOTABUG | QA Contact: | ceph-qe-bugs <ceph-qe-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | asriram, branto, gfidente, ipilcher, kdreyer |
Target Milestone: | rc | ||
Target Release: | 3.1 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-08-27 08:45:22 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1578730, 1609459 |
Description
Brad Hubbard
2017-10-06 03:03:38 UTC
Note that the postuninstall script also has the potential to restart the daemons. The daemon restart is by design. The daemons need to be down when they are being relabelled. Otherwise, they might just keep on writing improperly labelled files. However, we should document this and add a note that if you are running a hyperconverged scenario you should stop the daemons before the upgrade (so this won't really show up as an issue...) and start them after the upgrade. @Anjana: Why did you move this to 3.1? Are we not documenting that the admins should stop the daemons before the upgrade to 3.0 and start them after the upgrade to 3.0? Because if not, we definitely should. An example of where this can bite is here - https://bugzilla.redhat.com/show_bug.cgi?id=1609459 (which also explains how the mons can fail to restart). It also causes all OSDs to go down if 'yum update' is naïvely run simultaneously on all OSD nodes, which TripleO sometimes does. Note that I only hit this because running 'rhos-release 13' automatically subscribes the node to the Ceph 3 repos, and I didn't realize that wasn't supposed to happen as part of the OSP fast-forward upgrade workflow. It does seem like this is an awfully easy issue to hit. I suppose this might be fairly easy to hit if you do not follow the upgrade instructions when upgrading Ceph. AFAIK, we only require MONs to be restarted before OSDs in case of major upgrades and I certainly hope that we do document that you should stop the daemons before doing the major upgrade (iirc, we do). If the daemons are stopped during upgrade they won't be restarted by the post script that runs the relabelling so you won't run into issues like these. |