On 3/22/19 4:43 PM, Sam Just wrote:
As I mentioned on https://github.com/ceph/ceph/pull/27071 I'm pretty confident that the fastest way to get peering working in crimson is to extract the logic for dealing with the peering state, messages, and state transitions from PG.h into a module we can directly reuse in Crimson. As it happens, most of the heavy lifting was already done with the introduction of the state machine. Each peering message/event gets injected into the state machine and results in a set of side effects in the RecoveryCtx to be executed asynchronously. The handlers do not actually perform any IO or messaging operations except by populating RecoveryCtx. As such, in principle, it's already well suited to a seastar world. I've started working on that refactor. It's been straightforward (if fiddly and time consuming) so far to move RecoveryMachine along with the appropriate PG state (peer_info etc) and methods (proc_replica_info etc) into a separate file/class such that classicPG and crimsonPG are only referenced through a narrow interface for things like notification of state changes. Given that we want crimson to be compatible (at least for now) with RADOS as we know it, I think this is probably the right path. Of course, adopting the existing protocol does mean adopting some of the same overhead in that we still in some sense need to persist certain log/info structures required by peering -- though we can of course do it in a radically different way or ignore some of the IO overhead for testing purposes. Nevertheless, I think it represents at least a decent next step. -Sam
That is awesome Sam. Glad to have you back. :) Mark
