pulp / pulp/pulpcore

task created_resources provides hrefs, but no guidance on how to determine the type from the href

Open
#2,028 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

Author: @jlsherrill (jsherril@redhat.com)

Redmine Issue: 9099, https://pulp.plan.io/issues/9099


Currently an rpm sync task with mirror=true provides mutliple types of created_resources, a version_href and a publication_href.

It is left up to the user to figure out how to map an href to a particular object. This is made more difficult when you consider that we'd want code to detect this generically across all content types without having to code for each one.

Its easy to write a regex that would match version href for example:

   /.*\/versions\/.*/

However this would match other href's as well, we could expect an id:

/.*\/versions\/\d*\//

but this depends on them being numerical, is that okay? Will that break in the future?

It would be helpful to have some set of regex's or some guidance on how to determine if a given href is a:

  • repository
  • version
  • publication
  • distribution

across all content types, with a commitment that (at least for pulp3), that these regexs or guidance will not change.

This could be verified with a unit_test at the code level.

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 tracing the rpm sync task's created_resources, version_href, and publication_href handling, then review how repository, version, publication, and distribution hrefs are represented across content types. Define stable matching guidance and verify it with a unit test, including whether numeric IDs are part of the contract.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.