Project

General

Profile

Actions

Feature #7758

closed

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

Added by Josh Baird over 9 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Repositories
Target version:
-
Difficulty:
Triaged:
Yes
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.

Actions #1

Updated by Eric Helms over 9 years ago

  • Triaged changed from No to Yes
Actions #2

Updated by Eric Helms over 8 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?

Actions #3

Updated by Eric Helms over 8 years ago

  • Status changed from Needs design to Need more information
Actions #4

Updated by Eric Helms over 8 years ago

  • translation missing: en.field_release set to 114
Actions #5

Updated by John Mitsch over 4 years 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.

Actions #6

Updated by Justin Sherrill over 4 years ago

  • Target version deleted (Katello Backlog)
Actions #7

Updated by Justin Sherrill over 4 years ago

  • Status changed from Closed to Rejected
Actions

Also available in: Atom PDF