Task #2178

Remove the conduits and port usage to use the progress API

Added by bmbouter over 4 years ago. Updated over 1 year ago.

Start date:
Due date:
% Done:


Estimated time:
Platform Release:
Sprint Candidate:


The conduits are in platform[0] so they should be removed from there. Once removed many plugin codepaths and maybe some platform codepaths will break. They should be updated to use the new progress reporting models introduced with #2092. Replacement with direct Django querying is ok too if models are available when this refactor is done. Other non-progress reporting usages of the conduits should probably be brought up for discussion about how to handle to be sure that what we are replacing them with is stable.

Since the conduits are no longer available for usage with 3.0, we should remove references to them in the documentation also. That is part of this story. Adding docs is part of another story, so don't add docs, just remove them.




#1 Updated by bmbouter over 4 years ago

  • Blocked by Task #2092: Create django model(s) for progress reporting added

#2 Updated by bmbouter over 4 years ago

  • Checklist item Remove conduits package added
  • Checklist item port platform and all plugins added
  • Checklist item remove docs referencing the conduits added
  • Description updated (diff)

#3 Updated by bmbouter over 4 years ago

  • Tracker changed from Refactor to Task

#4 Updated by over 4 years ago

  • Description updated (diff)
  • Groomed changed from No to Yes

#5 Updated by mhrivnak over 4 years ago

  • Groomed changed from Yes to No

I expect each plugin will require a giant refactor to remove either the step system or whatever custom reporting workflow is in place, and re-organize it into a new workflow that makes use of the new progress reporting. Recall that with the step system, it does a lot (or all) of the reporting for you, so it's not easy to replace that without reorganizing a ton of code.

There's also the issue of replacing the importer and distributor base classes that will have an impact on refactoring the plugins. Not to mention making new django models for units and using them.

So I suggest breaking this up into a separate task for each plugin to convert its use, plus a task for the platform.

I suspect we'll end up having a developer start working on a particular plugin and grab a few tasks to all do together. Those would include things like "Use the new progress reporting", "Use the new django models", and "Use the new plugin base classes". I think it'll be easiest to do them all approximately at once than try to change just one at a time and produce something that still works.

I'm going to un-groom this for further discussion.

#6 Updated by bmbouter over 4 years ago

You've identified a lot of great details in this work. Breaking it up into these parts sounds really good. Would you make those redmine tasks?

#7 Updated by bmbouter over 3 years ago

  • Blocked by deleted (Task #2092: Create django model(s) for progress reporting)

#8 Updated by bmbouter over 3 years ago

The progress API will be used as each plugin is ported. The old conduit code will be removed eventually when all the /server code is removed. The old docs will be removed when the /old_docs folder is deleted. Given all ^ I'm going to close this issue since it doesn't really make sense any more given the current state.

#9 Updated by bmbouter over 3 years ago

  • Status changed from NEW to CLOSED - NOTABUG

#10 Updated by daviddavis over 1 year ago

  • Sprint/Milestone set to 3.0.0

#11 Updated by bmbouter over 1 year ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF