pulp / pulp/pulpcore

Provide ability to filter signing services by type

Open
#4,952 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Feature
Dominant language
Python
Stars
598
Forks
168
Avg merge
1d 4h
Merged PRs (30d)
86

Description

Is your feature request related to a problem? Please describe.

The issue was originally discussed as a Pulp CLI issue: https://github.com/pulp/pulp-cli/issues/779
That discussion came to the conclusion that the feature needs to be implemented in pulpcore.

Different plugins may subclass different signing services with the expectation that all plugin actions using a signing service must use a signing service of the appropriate type! However, it is currently not trivial to list signing services by type, since they are all accessed via the same pulpcore endpint.

Describe the solution you'd like
It was suggested that the best solution would be a type field on the signing service serializer class, along with a filter to filter by this field.
Ideally plugins that subclass the signing server serializer class do not need to "remember" to define the type field. Perhaps it can simply be derived from the class name?

Additional context
How I ultimately imagine this working in pulp-cli:

pulp signing-service --type AptReleaseSigningService list

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the pulpcore signing service serializer class and the endpoint that exposes all signing services. Read the linked Pulp CLI discussion for the expected filtering behavior, then inspect how serializer fields and filters are defined. Done means plugins can filter signing services by type without manually repeating the type definition, with coverage for the proposed CLI use case.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.