Project

General

Profile

Subtask #4928

PG/ReplicatedPG API

Added by Loïc Dachary almost 11 years ago. Updated almost 11 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
OSD
Target version:
-
% Done:

10%

Spent time:
Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

work in progress

  • The goal is not to factor out a base class from which an ErasureEncodedPG could be derived, it is to reverse engineer the PG API
  • PG/ReplicatedPG are really a single class although they grew from two different classes, back when RAID4 was to be implemented : the difference between the two gradually disapeared
  • Define an API ( IPG ? ) class for PG/ReplicatedPG
  • Change the code using PG/ReplicatedPG to use the API class rather than the actual PG/RepliatedPG classes
    • this may involve modifying the code of the calling classes to use accessors when data members are referenced
    • the callers are not otherwise modified, to minimize the change
    • it is assumed that the the API is defined by what is used and no attempt is made to improve
  • Tests are written for the API to cover 100% of the LOC and most of the expected functionalities implemented by PG/ReplicatedPG.

History

#1 Updated by Loïc Dachary almost 11 years ago

  • Parent task set to #4929

#2 Updated by Loïc Dachary almost 11 years ago

  • Description updated (diff)

#3 Updated by Loïc Dachary almost 11 years ago

  • Description updated (diff)

#4 Updated by Loïc Dachary almost 11 years ago

  • % Done changed from 0 to 10

#5 Updated by Loïc Dachary almost 11 years ago

  • Status changed from 4 to Rejected
  • translation missing: en.field_remaining_hours set to 0.00
(07:54:30 PM) sjust: I think the IPG stuff is a bit premature
(07:55:38 PM) sjust: for example, a PG interface probably shouldn't have get_need_up_thru
(07:55:52 PM) sjust: instead, the pg should register a request for an up_thru change with the OSD
(07:56:10 PM) sjust: anyway, the first step is to factor out components from the PG as much as possible
(07:56:14 PM) sjust: they will be easier to test
(07:56:23 PM) sjust: and it will make it easier to specify the IPG interface later
(07:57:47 PM) sjust: IPG wouldn't specify an ObjectContext implementation necessarily either
(07:58:27 PM) sjust: that should be relocated into it's own component which handles object locking and object context ref tracking
(07:58:45 PM) sjust: same with RepGather
(07:59:08 PM) sjust: both are just internal details of how ReplicatedPG (and hopefully also ErasureCodedPG) manage in progress IO

#6 Updated by Loïc Dachary almost 11 years ago

  • Estimated time set to 0.00 h
  • Parent task deleted (#4929)

Also available in: Atom PDF