Bug 2134135
| Summary: | Ceph OSDs not being restarted after configuration change | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Ceph Storage | Reporter: | alisci <alisci> |
| Component: | Ceph-Ansible | Assignee: | Teoman ONAY <tonay> |
| Status: | ASSIGNED --- | QA Contact: | Vivek Das <vdas> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.0 | CC: | aschoen, ceph-eng-bugs, cgussobo, dhill, gjose, gmeno, nthomas, tonay |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | 4.3z2 | Flags: | alisci:
needinfo?
(tonay) |
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-02-14 14:42:51 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: | |||
Description of problem: When we update the ceph-ansible configuration and run a stack update, we expect to see all the Ceph OSDs being restarted in order to pick up the new configuration. In RHOSP 16.1 this is what we always observed. However in 16.2 this does not happen, and in order for changes to be picked up we must manually restart the containers. Version-Release number of selected component (if applicable): OSP 16.2.3 ceph-ansible-4.0.70.3-1.el8cp.noarch ceph containers: rhceph/rhceph-4-rhel8 4-69.1638383142 ceph-base-14.2.11-208 How reproducible: change a osd memory config by adding a template that uses CephAnsibleExtraConfig and osd_memory_target ; then do a deployment with that parameter_defaults: CephAnsibleExtraConfig: osd_memory_target: 6123456789 Actual results: despite the fact that after the deployment changes ar did at /etc/ceph/ceph.conf , new values for "osd memory target" are not applied and needed osd container to restart to having effect Expected results: after the deployment new config for osd should be active without their container restart, or some indications in the docs are needed if this is assumed to be an expected result Additional info: