Provide ability to filter signing services by type
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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