It's a bit wonky to have something in pulp_rpm.common use objects that only exist in the server. Consider pulling out the data portions of the progress report, both storage of values and parsing/recreation, from the server-side logic, which can then exist in the plugin as either a utility or a subclass.

The docstring further talks to this point. You have a single method that has text instructions about which parameters are used in which case. According to the docs, there's no overlap in when those parameters would be used, which makes the API look like you crammed two very different methods into a single signature.

An alternative if you want to keep everything in this class would be factory methods at the class level. Something along the lines of

def server_report(conduit):
   return ISOProgressReport

def client_report(all-the-other-parameters):
  return ISOProgressReport

It's still messy OO though, especially if you leave the naming like my example, but it beats having a single signature with a description that says when each parameter would apply.