Skip to content
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

[release-3.10] Fix broken update handling of path-based routes #21903

Merged

Conversation

ironcladlou
Copy link
Contributor

This is a backport of #21877.

When an existing route's path is updated to a new value not previously observed,
the new route state is correctly activated, but the previous route is not
replaced in the `hostRules` internal active list. Instead, the updated route
state (with a different path but duplicate UID) is appended to the active list.
A `hostRules` active list with more than one route instance sharing a UID and
host is an invalid internal state. The net effect is some unintended confusing
behavior which manifests when updating the route's path, including:

  * Updating from path A->B->A preventing future transitions to B

  * Updating from path A->B->A->B leaves an orphaned claim on the host in the
namespace, preventing the recreation of the route with either of the previously
observed paths until the router is restarted (causing the internal state to be
rebuilt)

Routes updates which are affected by this bug will be rejected with a status
like:

    message: route foo already exposes foo-ns.os.example.com and is older
    reason: HostAlreadyClaimed

Where `foo` refers to itself. This indicates the route update was rejected due
to a claim made by the same route being updated.

To fix the problem, ensure that when a path change is detected on the same route
the prior existing state is removed from the index, eliminating the possibility
of keeping an orphaned claim. Then add the new route as usual, which handles
acceptance/rejection normally.
@openshift-ci-robot openshift-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jan 29, 2019
@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 29, 2019
@ironcladlou
Copy link
Contributor Author

/retest

@Miciah
Copy link
Contributor

Miciah commented Jan 30, 2019

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 30, 2019
@openshift-merge-robot openshift-merge-robot merged commit 67ef696 into openshift:release-3.10 Jan 30, 2019
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ironcladlou, Miciah

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link

@pravisankar pravisankar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants