Project

General

Profile

Feature #7758

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

Added by Josh Baird almost 5 years ago. Updated about 1 year ago.

Status:
Need more information
Priority:
Normal
Assignee:
-
Category:
Repositories
Target version:
Difficulty:
Triaged:
Yes
Bugzilla link:
Pull request:
Team Backlog:
Fixed in Releases:
Found in Releases:

Description

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.

History

#1 Updated by Eric Helms over 4 years ago

  • Triaged changed from No to Yes

#2 Updated by Eric Helms almost 4 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 4 years ago

  • Status changed from Needs design to Need more information

#4 Updated by Eric Helms over 3 years ago

  • Legacy Backlogs Release (now unused) set to 114

Also available in: Atom PDF