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

consul/connect: in-place update service definition when connect upstreams are modified #10776

Merged
merged 1 commit into from
Jun 17, 2021

Conversation

shoenig
Copy link
Member

@shoenig shoenig commented Jun 16, 2021

This PR fixes a bug where modifying the upstreams of a Connect sidecar proxy
would not result Consul applying the changes, unless an additional change to
the job would trigger a task replacement (thus replacing the service definition).

The fix is to check if upstreams have been modified between Nomad's view of the
sidecar service definition and the service definition for the sidecar that is
actually registered in Consul during service reconciliation.

Fixes #8754

…eams are modified

This PR fixes a bug where modifying the upstreams of a Connect sidecar proxy
would not result Consul applying the changes, unless an additional change to
the job would trigger a task replacement (thus replacing the service definition).

The fix is to check if upstreams have been modified between Nomad's view of the
sidecar service definition, and the service definition for the sidecar that is
actually registered in Consul.

Fixes #8754
Copy link
Member

@tgross tgross left a comment

Choose a reason for hiding this comment

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

LGTM with the one caveat about maintenance.

return true
case A.MeshGateway.Mode != B.MeshGateway.Mode:
return true
case !reflect.DeepEqual(A.Config, B.Config):
Copy link
Member

Choose a reason for hiding this comment

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

It looks like this big switch/case is a performance optimization to avoid doing reflect.DeepEqual on the api.Upstream if we can avoid it, but from a maintenance perspective this seems like it's brittle. If we upgrade the Consul library and they add new fields this check will silently break.

(Alternately, is there maybe a way we can write a unit test that automatically gives us non-default values for all fields so that we have a breaking test on upgrade? I don't know of one off the top of my head but that would be really cool.)

Copy link
Member Author

@shoenig shoenig Jun 17, 2021

Choose a reason for hiding this comment

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

I think you just gave me an excuse to play around with https://blog.golang.org/fuzz-beta 🙂

Using reflect.DeepEqual is similarly dangerous, for example it always returns false if a function is added to the struct fields:
https://play.golang.org/p/Yfu4d2RdTKd

Really thought the only correct thing to do here would be fore Consul to provide equality methods in their api package - they are the ones who define what the thing is and know how it compares.

Copy link
Member

Choose a reason for hiding this comment

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

Totally agreed there.

@shoenig shoenig merged commit 2d8fc6b into main Jun 17, 2021
@shoenig shoenig deleted the b-cns-sysjob-ups branch June 17, 2021 15:13
notnoop pushed a commit that referenced this pull request Jun 22, 2021
consul/connect: in-place update service definition when connect upstreams are modified
@notnoop notnoop modified the milestones: 1.1.3, 1.1.2 Jul 28, 2021
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

System jobs require restart after adding upstreams
4 participants