I'm not sure I understand, by PG::RecoveryStats, do you mean PG::RecoveryState? -Sam
On Fri, Jun 21, 2013 at 6:37 AM, Loic Dachary <[email protected]> wrote: > Hi Sage, > > In order to move the PG peering code out of PG.{cc,h} (which is the next step > in refactoring PGs as suggested by Sam > http://pad.ceph.com/p/Erasure_encoding_as_a_storage_backend ) I think it > would be sensible to: > > * Move PG::RecoveryStats in PGRecoveryStat.{cc,h} > * Create PGInterface : an abstract base class for PG enumerating all PG > methods used by PGRecoveryStats > * Move Peering states / methods out of PGRecoveryStat.{cc,h} and into > PGPeering.{cc,h} > * Write tests for PGPeering.{cc,h}, using a fixture derived from PGInterface > > Because this approach not only moves the peering out of PG.{cc,h} but also > the rest of the state logic, I would like to know if this seems sensible to > you. Also, introducing an abstract base class to help isolate the PG > interface and facilitate writing fixtures has not been discussed yet. > > Cheers > > -- > Loïc Dachary, Artisan Logiciel Libre > All that is necessary for the triumph of evil is that good people do nothing. > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
