Add object labels
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: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
Labels are arbitrary key value pairs that can be applied to objects and used to query them. For example, I could attach a
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
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
- separate inbound repos with
- identify which repositories contain certified content with
#3 Updated by firstname.lastname@example.org 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.
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