Fixed KeyError during publish for unmatched arch

[daviddavis]

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.

[quba42]

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.

[quba42]

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.

[quba42]

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.

[quba42]

Reproduced the error and verified the fix for the 2.18 branch. Will add backport tags.

[patchback]

Backport to 2.18: 💚 backport PR created

✅ Backport PR branch: patchback/backports/2.18/5409a143db136ae09b11f16b3945ee6269d52529/pr-778

Backported as #786

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback]

Backport to 2.19: 💚 backport PR created

✅ Backport PR branch: patchback/backports/2.19/5409a143db136ae09b11f16b3945ee6269d52529/pr-778

Backported as #787

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback]

Backport to 2.20: 💚 backport PR created

✅ Backport PR branch: patchback/backports/2.20/5409a143db136ae09b11f16b3945ee6269d52529/pr-778

Backported as #788

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.

[patchback]

Backport to 2.21: 💚 backport PR created

✅ Backport PR branch: patchback/backports/2.21/5409a143db136ae09b11f16b3945ee6269d52529/pr-778

Backported as #789

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.