Story #7127

Add object labels

Added by newswangerd 5 months ago. Updated 10 days ago.

Start date:
Due date:
% Done:


Estimated time:
Platform Release:
Sprint Candidate:



As a developer, it would be nice to be able to label pulp objects such as repositories. To accomplish this, I propose adding Kubernetes style labels to pulp objects (more information on kubernetes labels here:

Labels are arbitrary key value pairs that can be applied to objects and used to query them. For example, I could attach a label1=foo, label2=foo, and label3=foobar to a repository. The repository could then be queried by any of the following methods

  • foo=bar: select all objects that have the foo label set to bar
  • foo!=bar: select all objects that have the foo label set to anything except bar
  • foo in (bar, foobar): selects all objects with the foo label that contain either the values for bar or foobar
  • foo notin (bar, foobar): selects all objects with the foo label that don't contain bar or foobar
  • foo: selects all objects that contain the label foo (regardless of value)
  • !foo: selects all objects that don't contain the label foo

Use cases

In galaxy_ng we need a way to filter repositories based on what they are used for. For example we are going to have the following repositories

  • published - contains locally published collections. Should be searchable. Is the default repo if no repo is provided
  • staging - content waiting for approval. Not searchable
  • rejected - content that has been rejected. Not searchable
  • rh-certified - content synced from automation hub. Contains red hat certified content. Searchable
  • community - content synced from galaxy. Searchable

As well as an arbitrary number of repositories named inbound-<namespace_name> for uploading collections. Not searchable.

Right now the names for these repos are hard coded as a way for the API to identify which content should go where, however with label support we could add the following labels

  • searchable= true | false
  • default=true | false
  • content-readiness= production | inbound | staging
  • certification= community | rh-certified | local

With these labels we can:

  • limit search results to repos that match searchable=true
  • separate inbound repos with content-readiness!=inbound
  • identify which repositories contain certified content with certification=rh-certified

Related issues

Related to Pulp - Story #5510: I would like to have an option to associate key-value pair to repository - former "Notes" field in Pulp 2NEW

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>
Has duplicate Pulp - Story #5279: As a user I can label pulp resourcesCLOSED - DUPLICATE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>


#1 Updated by bmbouter 5 months ago

  • Has duplicate Story #5279: As a user I can label pulp resources added

#2 Updated by fao89 5 months ago

  • Tracker changed from Issue to Story
  • % Done set to 0
  • Severity deleted (2. Medium)
  • Triaged deleted (No)

#3 Updated by 4 months ago

Hearing from other stakeholders, the only limitation that would be good to drop is the Kubernetes style labels rules. Namely:

  • drop 63 characters limit for both key and value
  • value must be empty or begin and end with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between. --> release these rules so for example '/' are allowed.

#4 Updated by about 2 months ago

  • Related to Story #5510: I would like to have an option to associate key-value pair to repository - former "Notes" field in Pulp 2 added

#5 Updated by daviddavis 11 days ago

A couple possibilities for how the API param might work:

  • labelSelector=environment%3Dproduction,tier%3Dfrontend (from the Kubernetes docs)
  • labelSelector=foo=bar&labelSelector=bar=foo

#6 Updated by dalley 10 days ago

I'd kind of like to do this in a way that might solve multiple pain points at once.

Create a new "resource" model type which holds the following data:

  • The pulp_href, stored pre-computed, with a unique index
  • The tags. We can probably use Postgresql HStoreField for this, it's where we should start. If not then we could attach whatever data we want to this model.
  • A generic foreign key to the database object.

"Resource" would take over from the "CreatedResource", and task would have a nullable foreign key to Resource rather than CreatedResource having a FK to Task.


  • Tags only need to be stored in one place
  • It's possible to search tags across all resource types at once
  • It enables solving the problem where CreatedResource objects in the task records to go to null


  • Managing a separate surrogate model that needs to be created whenever a new "resource" is created and deleted vice-versa may be difficult.

Please register to edit this issue

Also available in: Atom PDF