Story #3450
closedAs a user I would like to limit the tags we sync for docker repos
100%
Description
Motivation:
We're currently sync'ing some very large openshift repos from brew. In reality we're only interested in the current 3.9 and newerreleases/tags but we're getting everything, which is weighing in at 1.2TB at present and growing with each puddle for each version.
It would be nice to be able to limit the tags we sync.
Solution:
Provide a config on the DockerImporter config called "tags". This config will accept a list of tags to sync.
Provide a CLI option called "--tags". The user will be able to specify "--tags" when creating a docker repository. The user will also be able to override the "--tags" importer config at sync time, by specifying it as part of the override_configs.
When the "tags" option is provided:
Pulp will sync just those tags + manifests associated with the tags and all the corresponding layers. Sync will only be performed using the immediate download policy. There will be no support for the on_demand download policy.
Note: If the list of tags was changed, and tag X is not wanted anymore, a manual removal of that tag X should occur in the local repo.
Note: If some invalid tags provided are invalid, Pulp will only sync the available ones in the remote repo.
When the "tags" option is not provided:
Pulp will sync the whole repo.
Related issues
Updated by tomckay@redhat.com over 6 years ago
This usage would also be useful with foreman as well. I can see two ways:
1. Provide a tag filter up front to limit tags pulled down
2. Just pull the metadata files for the tags and sync the actual images later (exactly like for RPM units)
Personally, I would prefer the second option.
Updated by ipanova@redhat.com over 6 years ago
- Has duplicate Story #3137: As a user, I can view docker image Arch and Size Information through the REST API added
Updated by ipanova@redhat.com over 6 years ago
- Has duplicate deleted (Story #3137: As a user, I can view docker image Arch and Size Information through the REST API)
Updated by ipanova@redhat.com over 6 years ago
- Has duplicate Story #3623: As a user I can sync a registry by whitelisting tags ( Filtered Sync) added
Updated by ipanova@redhat.com over 6 years ago
an option will be provided where a list of tags to sync can be specified. for example --tags
if option is provided:
we will sync just those tags + its' manifests + correspondent layers. Sync is performed in immediate poilicy, no on_demand.
note if the list of tags was changed, and tag X is not wanted anymore, a manual removal of that tag X should occur in the local repo.
note if some of invalid tags where provided in the list to sync, we will sync just available ones in the remote repo.
if option is not provided:
we will sync by default whole repo.
Updated by ipanova@redhat.com over 6 years ago
- Sprint Candidate changed from No to Yes
Updated by bizhang over 6 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to bizhang
Updated by bizhang over 6 years ago
- Status changed from ASSIGNED to POST
Added by werwty over 6 years ago
Added by werwty over 6 years ago
Revision e46d3b3e | View on GitHub
Add feature to whitelist tags on sync.
Updated by werwty over 6 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset e46d3b3ee31f31fe5d83958bc96dbf1e9ffef32a.
Updated by dkliban@redhat.com over 6 years ago
- Platform Release deleted (
2.16.2)
Updated by amacdona@redhat.com over 6 years ago
- Platform Release deleted (
2.16.2)
Updated by rchan over 6 years ago
- Sprint/Milestone set to 2.17.0
Adding to 2.17.0 milestone. This is one of the required deliverables.
Updated by ipanova@redhat.com over 6 years ago
- Platform Release changed from 2.17.0 to master
Updated by ipanova@redhat.com over 6 years ago
- Platform Release deleted (
master)
Updated by ipanova@redhat.com over 6 years ago
- Status changed from MODIFIED to 5
Updated by ipanova@redhat.com about 6 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
Add feature to whitelist tags on sync.
closes #3450 https://pulp.plan.io/issues/3450