Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2019-10-29T02:16:15ZCeph
Redmine RADOS - Bug #42519 (New): During deployment of the ceph,when the main node starts slower than the...https://tracker.ceph.com/issues/425192019-10-29T02:16:15Zhe huang
<p>During deployment of the ceph, the main MON node starts slowly, and the other two nodes start first and complete the election. At this time, the name of the main mon in the monmap is still the noname-a, but there is IP. When the main mon starts, it launches the probe. After receiving the probe_reply, it finds that other nodes' momap is newer than its own, so it directly updates other nodes' momap, but at this time, the updated momap does not have the main node’s name. After that, the main node choose itself as the main mon and enter the timecheck process. Since there is no name of the main node in the momap, the main node think that all three mons in quorum need to be checked.So the main node send a message to three mons and wait for response. But in fact the main node should only be sent to two Mon, which leads to the lack of one response message during check and the core generated by assert.</p> RADOS - Bug #16258 (New): ceph audit logs are not logging to ceph.audit.log if we specify "mon cl...https://tracker.ceph.com/issues/162582016-06-13T10:06:39Znaga venkata bokkanaga.b@hpe.com
<p>In ceph.conf if we specify option "mon cluster log file" both audit and cluster logs are going into the same file ceph.log(no ceph.audit.log file created), if i don't specify this option two separate logs for cluster logging and audit logging (ceph.log and ceph.audit.log) are created.</p> RADOS - Cleanup #10506 (New): mon: get rid of QuorumServiceshttps://tracker.ceph.com/issues/105062015-01-10T03:54:34ZJoao Eduardo Luis
<p>A QuorumService is an abstraction allowing for easier management of services requiring a quorum to work correctly.</p>
<p>While it seemed like a good idea at the time, hopeful of being useful for the future expansion of the monitor in terms of in-memory-only services (say, for health purposes), it turned out to be a slight annoyance code-wise.</p>
<p>At the moment, we have 3 services defined in mon/QuorumService.h: HEALTH, TIMECHECK, CONFIG_KEY. Of these, only two are built using the QuorumService class: HealthService and ConfigKeyService. Timechecks are embedded in the Monitor class code.</p>
<p>HealthService is another mind boggling piece of code: defines a HEALTH_DATA service and is implemented by mon/HealthMonitor.cc, which in turn will manage mon/DataHealthService.cc, the latter being responsible for tracking monitor disk usage across the quorum.</p>
<p>Given the small usefulness of this infrastructure compared to its large footprint, I would very much enjoy getting rid of it all or implement it in a way that's so trivial that doesn't make my head hurt.</p>