Open quba42 opened 1 year ago
The issue is that signing services are not master-detail like remotes et al. There is no filter to achieve this either:
$ pulp -p container debug openapi operation --id signing_services_list | jq '.operation.parameters[].name'
"limit"
"name"
"offset"
"ordering"
"pulp_href__in"
"pulp_id__in"
"fields"
"exclude_fields"
and it looks like the pulp_href is the only discriminator today:
pulp -p container debug openapi schema --name SigningServiceResponse
{
"type": "object",
"description": "A serializer for the model declaring a signing service.",
"properties": {
"pulp_href": {
"type": "string",
"format": "uri",
"readOnly": true
},
"pulp_created": {
"type": "string",
"format": "date-time",
"readOnly": true,
"description": "Timestamp of creation."
},
"name": {
"type": "string",
"description": "A unique name used to recognize a script."
},
"public_key": {
"type": "string",
"description": "The value of a public key used for the repository verification."
},
"pubkey_fingerprint": {
"type": "string",
"description": "The fingerprint of the public key."
},
"script": {
"type": "string",
"description": "An absolute path to a script which is going to be used for the signing."
}
},
"required": [
"name",
"pubkey_fingerprint",
"public_key",
"script"
]
}
@mdellweg Do you think perhaps it would make sense to explicitly add a "type" field (or similar) to the SigningService
base class?
AFAIK you can currently supply signing services of the wrong type to the API, and it will simply try to use it instead of providing a clear error message for that particular user error. Maybe the fact that there are signing services of very different types needs to be made much more explicit in general (not just for Pulp CLI)?
I agree. I cannot recall the reasons why we didn't use the master-detail in the first place. But also i think https://github.com/pulp/pulp_deb/blob/main/pulp_deb/app/serializers/publication_serializers.py#L42 Should limit to the proper choice.
Given the discussion, it seems CLI needs to wait for a pulpcore change to make this possible. Leaving this open for if/when/as such a thing happens.
@mdellweg Do you think we should open a pulpcore issue?
Is this still a thing? At that point, i think a type field in the pulpcore serializer together with an appropriate filter is in order. Would you create an issue to that end?
Summary
When using signing services it is essential to use the correct type of signing service. Using
AsciiArmoredDetachedSigningService
where the plugin expectsAptReleaseSigningService
won't work.However, the
pulp signing-service
command does not appear to know a--type
option.Examples
I want to be able to do something like:
To list just the signing services of the specified type.
Challenges
I am not sure how problematic it is that
pulp signing-service
is a pulpcore associated command, while many signing service types may be plugin specific.