pulp / pulp/pulp_container

base_path uniqueness constraint prevents syncing the same image from multiple remote registries

Open
#2,495 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Question
Dominant language
Python
Stars
31
Forks
56
Avg merge
2d 22h
Merged PRs (30d)
22

Description

Summary

When the same container image path (e.g. library/mysql) is synced from
multiple remote registries, Pulp rejects the second and subsequent
distributions with a base_path uniqueness error.

Tags from the same image across different registries cannot be served
under a single distribution.


Current Behaviour

Remote registry Image Derived base_path Result
docker.io library/mysql library/mysql ✅ Created
100.10.1.114:443 library/mysql library/mysql ❌ Rejected
100.10.1.114:3445 library/mysql library/mysql ❌ Rejected

Error returned:

{"base_path": ["This field must be unique."]}

Note: Multiple tags of the same image from the same registry sync
and distribute correctly. The issue only occurs when different remote
registries
provide tags for the same image path.


Expected Behaviour

If tags are coming from different registries for the same image, Pulp
should support serving them through the same distribution with the same
base_path. The unified tag list from all upstream sources should be
accessible to clients under a single namespace.


Reproduction Steps

# 1. Create remote A (public registry)
pulp container remote create \
  --name "mysql-dockerhub" \
  --upstream-name "library/mysql" \
  --url "https://registry-1.docker.io" \
  --include-tags "8.0 8.4"

# 2. Sync remote A → repo A
pulp container repository create --name "mysql-a"
pulp container repository sync --name "mysql-a" --remote "mysql-dockerhub"

# 3. Create distribution A  →  succeeds
pulp container distribution create \
  --name "mysql-dist" \
  --base-path "library/mysql" \
  --repository "mysql-a"

# 4. Create remote B (private registry, different tags)
pulp container remote create \
  --name "mysql-private" \
  --upstream-name "library/mysql" \
  --url "https://100.10.1.114:443" \
  --include-tags "8.0-custom 8.4-patched"

# 5. Sync remote B → repo B
pulp container repository create --name "mysql-b"
pulp container repository sync --name "mysql-b" --remote "mysql-private"

# 6. Create distribution B  →  FAILS
pulp container distribution create \
  --name "mysql-dist-private" \
  --base-path "library/mysql" \
  --repository "mysql-b"
# ERROR: {"base_path": ["This field must be unique."]}

Related Issues

  • #2164Expose Image Tags in Pulp Container Distribution / CLI
    — that issue added support for exposing tags within a single
    remote/repository. This issue extends the same need across multiple
    remotes/registries
    for the same image path.

Use Case

In enterprise environments it is common to mirror the same image from
multiple upstream registries (public + private, or primary + DR site) and
present them behind a single namespace to consumers. Currently there is
no way to achieve this in Pulp when the image path is identical across
registries.

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 reproducing the conflict with the documented pulp container remote, repository sync, and distribution create commands for two registries. Investigate how distributions enforce base_path uniqueness and how repositories are associated with distributions. Done means tags from multiple registries can be served under one image path without the uniqueness error, while existing same-registry behavior remains intact.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, python
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.