This repository has been archived by the owner on Dec 7, 2022. It is now read-only.
Sync v1 and v2 content when the registry support it. #119
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
| v2_found = self.index_repository.api_version_check() | ||
| v1_found = self.v1_index_repository.api_version_check() | ||
| # TODO: REMOVE THIS |
There was a problem hiding this comment.
Austin wrote:
@rbarlow https://github.com/rbarlow remove this :)
my brain is running low on thinking from doing too much work. Fixed.
Randy Barlow
irc: bowlofeggs
pulp-docker used to try v2 and fall back to v1 if v2 was not supported. This commit causes pulp-docker to sync both for registries that support them. https://pulp.plan.io/issues/1449 re #1449
bowlofeggs
force-pushed
the
backport-1449
branch
from
e0b7618
to
24b1abe
Compare
| working_dir=working_dir)) | ||
| if v1_found: | ||
| _logger.debug(_('v1 API found')) | ||
| self.add_child(v1_sync.SyncStep(repo=repo, conduit=conduit, config=config, |
There was a problem hiding this comment.
I assume that it is deliberate that neither v1/v2 can be turned off/on?
There was a problem hiding this comment.
Austin wrote:
I assume that it is deliberate that neither v1/v2 can be turned off/on?
Indeed.
Randy Barlow
irc: bowlofeggs
|
I tried this with the upstream feed set to http://my-pulp-server:8888 and although the v2 sync worked, the v1 sync failed because it was trying to use port 5000 instead of port 8888. To be more specific: the /v1/repositories/.../images request gets its response (3 images), and the next thing to happen is a failed connection attempt to the wrong port (5000). |
|
After more investigation, it seems the incorrect-port issue was a configuration issue in my testing environment! Sorry. But now that's fixed, I'm seeing another issue. This traceback was from a sync operation from a v1+v2 Crane instance: |
|
Hello @twaugh! I was unable to reproduce the issue you linked. I spent today making two new environments so that I could use one to sync from the other. I put Crane in the "primary", and created a test repository that had v1 and v2 content in it. When I synchronized this repository with a "secondary" Pulp server running on another host, everything worked smoothly. For my test, I used a 2.8 Pulp as the "primary" because it is much easier for me to deploy. I actually did find a bug that affected 2.8 only in this process ( #120 ) but I don't believe that would have caused the traceback you saw. Are you able to consistently reproduce this issue? |
|
I am. (More information sent privately.) |
|
For others' benefit, @twaugh privately sent me a host URL to try this with that reproduces the issue he is experiencing. I can confirm that I am unable to sync with that URL, but I believe the URL itself was the problem not the sync code, as I am unable to retrieve some of the needed files. It looks like a publish may have aborted in the middle, leaving a half-published repository in place. I believe the code in this pull request does work, as I am able to sync from a Pulp 2.8 repository that has v1 and v2 published together, and the resulting publish on the "downstream" 2.6 repository appears to be sane. @twaugh can you look more closely at the published output on the system that hosts the feed URL in question? Here is some output from my Pulp 2.8 "parent" system to give you an idea of what I would expect to see: Obviously, you are testing with different Images and Manifests than I am so you will have different units, but that should give you a sense of the expected structure for both v1 and v2. |
|
Thanks, problem identified now. I've re-run my testing and I'm happy with this pull request. Thanks for helping diagnose the problems I was seeing! |
| self.sync_step = v1_sync.SyncStep(repo=repo, conduit=sync_conduit, config=config, | ||
| working_dir=working_dir) | ||
|
|
||
| self.sync_step = sync.SyncStep(repo=repo, conduit=sync_conduit, config=config, |
There was a problem hiding this comment.
Is it possible to determine which docker api version here? For the use case of syncing both, if we could do it here, we could then avoid having v1 and v2 sync as child steps of the same step.
There was a problem hiding this comment.
@asmacdo Unfortunately, this would prevent us from having one progress report per sync operation, which would not be compatible with Pulp's API.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
pulp-docker used to try v2 and fall back to v1 if v2 was not
supported. This commit causes pulp-docker to sync both for
registries that support them.
https://pulp.plan.io/issues/1449
re #1449