Feature #7758

As a user, I should be able to manage external Pulp servers/repositories

Added by Josh Baird over 5 years ago. Updated 9 months ago.

Target version:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:


If you already have a Pulp installation (especially with multiple nodes), Katello should be able to manage these instances and not force you to use a pulp-server that is included with Katello. It is my understanding that Katello<->Pulp communication is via the Pulp API, so I'm thinking this may be possible.


#1 Updated by Eric Helms over 5 years ago

  • Triaged changed from No to Yes

#2 Updated by Eric Helms almost 5 years ago

  • Status changed from New to Needs design

Currently we use Pulp as a vehicle to manage content and perform actions based upon our own data model and thus we require a 1-1 relationship for entities we create to Pulp entities. As I see it, there are a couple ideas here, some of which could use more information.

1) External Pulp for Scaling

This is the idea of being able to use Pulp installed on a separate server if you wanted to manage the scaling and disk size of it alone.

2) Importing an external Pulp

This is the idea of being able to point at another Pulp and import any repositories present there into Katello as a set of library repositories. You can essentially accomplish this today through repository discovery, but I could see a case for a specific way to import another Pulp directly. In this scenario, the external Pulp would remain only as an external repository source and not part of the infrastructure.

3) Managing an Existing External Pulp

In this scenario, the Pulp server would be brought in to the overall infrastructure, where the repositories would be imported and thus managed from there on out by Katello. This would likely require some editing/updating of attributes by Katello in order to manage them the way Katello currently expects. Further, this either require the development of methods to keep changes in sync if Pulp data is changed out of band or to restrict making changes out of band like we do today.

Which of these scenarios are you envisioning? What other or more detailed workflows would you like to see for your particular environment?

#3 Updated by Eric Helms almost 5 years ago

  • Status changed from Needs design to Need more information

#4 Updated by Eric Helms over 4 years ago

  • Legacy Backlogs Release (now unused) set to 114

#5 Updated by John Mitsch 9 months ago

  • Status changed from Need more information to Closed

Thanks for reporting this issue. This issue was created over 4 years ago and hasn't seen an update in 1 year. We are closing this in an effort to keep a realistic backlog. Please open up a new issue that includes a link to this issue if you feel this still needs to be addressed. We can then triage the new issue and reassess.

#6 Updated by Justin Sherrill 9 months ago

  • Target version deleted (Katello Backlog)

#7 Updated by Justin Sherrill 9 months ago

  • Status changed from Closed to Rejected

Also available in: Atom PDF