-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed KeyError during publish for unmatched arch #778
Conversation
This is an obvious improvement on the status quo of "somebody successfully uploaded a package with a new arch, now nobody can publish the repo". We probably also want to backport this to some existing release branches. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reproduced the bug (and verified the fix) using:
REMOTE_OPTIONS='--url=https://fixtures.pulpproject.org/debian/ --distribution=ragnarok --distribution=ginnungagap --distribution=nosuite --architecture=armeb --policy=on_demand'
ENTITIES_NAME='publish_wrong_arch_test'
${PULP_CLI_CMD} deb remote create --name=${ENTITIES_NAME} ${REMOTE_OPTIONS}
${PULP_CLI_CMD} deb repository create --name=${ENTITIES_NAME} --remote=${ENTITIES_NAME}
${PULP_CLI_CMD} deb repository sync --name=${ENTITIES_NAME}
REPOSITORY_HREF=$(${PULP_CLI_CMD} deb repository show --name=${ENTITIES_NAME} | jq -r .pulp_href)
TASK_HREF=$(${HTTP_CMD} --form post ${PULP_URL}/pulp/api/v3/content/deb/packages/ file@../frigg_1.0_ppc64.deb repository=${REPOSITORY_HREF} | jq -r .task)
${PULP_CLI_CMD} task show --href=${TASK_HREF}
ARCH_HREF=$(${HTTP_CMD} get ${PULP_URL}/pulp/api/v3/content/deb/release_architectures/?architecture='ppc64' | jq -r .results[0])
TASK_HREF=$(${HTTP_CMD} post ${PULP_URL}${REPOSITORY_HREF}modify/ remove_content_units:=[\"${ARCH_HREF}\"] | jq -r .task)
PUBLICATION_HREF=$(${PULP_CLI_CMD} deb publication create --repository=${ENTITIES_NAME} --structured --simple | jq -r '.pulp_href')
I have one nitpick regarding the warning message below. Apart from that this is ready to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self:
- I still need to decide whether to backport this to currently supported release branches.
- I want to open a follow up task to consider how this arguably inconsistent repo state can be prevented from arising in the first place.
Reproduced the error and verified the fix for the 2.18 branch. Will add backport tags. |
Backport to 2.18: 💚 backport PR created✅ Backport PR branch: Backported as #786 🤖 @patchback |
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
Backport to 2.19: 💚 backport PR created✅ Backport PR branch: Backported as #787 🤖 @patchback |
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
Backport to 2.20: 💚 backport PR created✅ Backport PR branch: Backported as #788 🤖 @patchback |
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
Backport to 2.21: 💚 backport PR created✅ Backport PR branch: Backported as #789 🤖 @patchback |
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
Fixed KeyError during publish for unmatched arch (cherry picked from commit 5409a14)
…136ae09b11f16b3945ee6269d52529/pr-778 [PR #778/5409a143 backport][2.21] Fixed KeyError during publish for unmatched arch
…136ae09b11f16b3945ee6269d52529/pr-778 [PR #778/5409a143 backport][2.20] Fixed KeyError during publish for unmatched arch
…136ae09b11f16b3945ee6269d52529/pr-778 [PR #778/5409a143 backport][2.19] Fixed KeyError during publish for unmatched arch
…136ae09b11f16b3945ee6269d52529/pr-778 [PR #778/5409a143 backport][2.18] Fixed KeyError during publish for unmatched arch
When publishing a package that doesn't have a matching architecture in the release component, a KeyError gets thrown. This fixes it so that a warning message is instead logged.
One option would have been to fail the publish with a more user friendly error. However, in our use case, repos are shared across different users/teams so if one team adds a package with an unsupported arch, no one can publish the repo (which is bad).
In the future, I think it would be good to add some validation to the repo modify endpoint to prevent packages with unsupported architectures from being added to repos.