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

Add an option to register services and their checks idempotently #4905

Merged

Conversation

ShimmerGlass
Copy link
Contributor

Fixes point #1 of: #4903

When registering several times a service on a local Agent using
/v1/agent/service/register, if checks are removed, those checks are not
removed from the service.
This change adds the option to be idempotent when registering services
and makes sure only specified checks are registered for the service when specifying &idempotent=true

Copy link
Contributor

@pierresouchay pierresouchay left a comment

Choose a reason for hiding this comment

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

LGTM, but a few changes:

  • handle properly '?idempotent' query param
  • add documentation

@@ -890,8 +890,15 @@ func (s *HTTPServer) AgentRegisterService(resp http.ResponseWriter, req *http.Re
}

// Add the service.
if err := s.agent.AddService(ns, chkTypes, true, token, ConfigSourceRemote); err != nil {
return nil, err
idempotent, _ := strconv.ParseBool(req.URL.Query().Get("idempotent"))
Copy link
Contributor

Choose a reason for hiding this comment

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

For the sake of consistency with other Consul APIs, you might check for parameter being present as true (similar to what is done in '&passing' or '&stale' for instance) (but handle false as you do still)

/agent/service/register => idempotent=false
/agent/service/register?idempotent => idempotent=true
/agent/service/register?idempotent=true => idempotent=true
/agent/service/register?idempotent=false => idempotent=false

@ShimmerGlass ShimmerGlass force-pushed the service-idempotent-registration branch from e2f870e to 64d7748 Compare November 6, 2018 17:22
Copy link
Contributor

@pierresouchay pierresouchay left a comment

Choose a reason for hiding this comment

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

LGTM

@ShimmerGlass
Copy link
Contributor Author

@i0rek done

Copy link
Member

@hanshasselberg hanshasselberg left a comment

Choose a reason for hiding this comment

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

Thanks for your work - I left a couple of comments, nothing major though! 🙏

agent/agent.go Outdated Show resolved Hide resolved
agent/agent.go Show resolved Hide resolved
agent/agent.go Outdated Show resolved Hide resolved
agent/agent.go Outdated Show resolved Hide resolved
agent/agent.go Outdated Show resolved Hide resolved
agent/agent.go Outdated Show resolved Hide resolved
agent/agent_endpoint.go Outdated Show resolved Hide resolved
@hanshasselberg
Copy link
Member

@Aestek I left a couple of comments earlier. just making sure you saw that.

@freddygv freddygv self-assigned this Jul 3, 2019
@pierresouchay
Copy link
Contributor

@Aestek Can you fix the remaining issues?

@ShimmerGlass ShimmerGlass force-pushed the service-idempotent-registration branch from 985e731 to f3b2db9 Compare July 10, 2019 12:25
@ShimmerGlass
Copy link
Contributor Author

@i0rek done (:

Copy link
Contributor

@freddygv freddygv left a comment

Choose a reason for hiding this comment

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

Thanks @Aestek, just have a few comments inline.

agent/agent_endpoint.go Outdated Show resolved Hide resolved
agent/agent_endpoint_test.go Outdated Show resolved Hide resolved
website/source/api/agent/service.html.md Outdated Show resolved Hide resolved
website/source/api/agent/service.html.md Show resolved Hide resolved
@ShimmerGlass ShimmerGlass force-pushed the service-idempotent-registration branch from f3b2db9 to 700c4e8 Compare July 11, 2019 08:33
@ShimmerGlass
Copy link
Contributor Author

thx @freddygv, fixed except the last point.

@ShimmerGlass ShimmerGlass force-pushed the service-idempotent-registration branch from 700c4e8 to b2a103b Compare July 12, 2019 13:32
@ShimmerGlass
Copy link
Contributor Author

@freddygv / @banks Done !

Copy link
Contributor

@freddygv freddygv left a comment

Choose a reason for hiding this comment

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

@Aestek I'm seeing a timeout in the following test when running it locally and in CI:
TestAgent_RegisterService_ReRegister_ReplaceExistingChecks

Can you please look into it? I ran it locally with:
go test -v -run TestAgent_RegisterService_ReRegister_ReplaceExistingChecks ./agent

Also, I found some outdated references to remove-old-checks, so I made some suggestions inline.

agent/agent_endpoint_test.go Outdated Show resolved Hide resolved
agent/agent_endpoint_test.go Outdated Show resolved Hide resolved
agent/agent_endpoint.go Outdated Show resolved Hide resolved
@freddygv
Copy link
Contributor

Hi @pierresouchay and @Aestek, can you please take a look at the test mentioned above.

We can get this merged once that's fixed.

@ShimmerGlass ShimmerGlass force-pushed the service-idempotent-registration branch from b2a103b to dd138aa Compare August 14, 2019 15:38
@ShimmerGlass
Copy link
Contributor Author

@freddygv Done ! The test was indeed hanging, a rebase miskate. This is fixed now

Copy link
Contributor

@freddygv freddygv left a comment

Choose a reason for hiding this comment

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

Thanks!

@freddygv
Copy link
Contributor

@Aestek we had to stop merging into master a couple of weeks ago until the final v1.6.0 was released. Now there are a couple merge conflicts in this PR. Can you please resolve them? We would like to include this change in v1.6.1, which is coming very soon.

@hanshasselberg hanshasselberg added the waiting-reply Waiting on response from Original Poster or another individual in the thread label Aug 27, 2019
When registering several times a service on a local Agent using
`/v1/agent/service/register`, if checks are removed, those checks are not
removed from the service.
This change adds the option to be idempotent when registering services
and makes sure only specified checks are registered for the service.
@ShimmerGlass
Copy link
Contributor Author

@freddygv done

@freddygv freddygv merged commit 7c7b7f2 into hashicorp:master Sep 2, 2019
@ShimmerGlass ShimmerGlass deleted the service-idempotent-registration branch September 3, 2019 08:29
@ShimmerGlass
Copy link
Contributor Author

Thx !

rboyer added a commit that referenced this pull request Sep 10, 2019
…th central config enabled

Also:

* Finished threading replaceExistingChecks setting (from GH-4905)
  through service manager.

* Respected the original configSource value that was used to register a
  service or a check when restoring persisted data.

* Run several existing tests with and without central config enabled
  (not exhaustive yet).

* Switch to ioutil.ReadFile for all types of agent persistence.

Fixes #6323
rboyer added a commit that referenced this pull request Sep 11, 2019
…th central config enabled

Also:

* Finished threading replaceExistingChecks setting (from GH-4905)
  through service manager.

* Respected the original configSource value that was used to register a
  service or a check when restoring persisted data.

* Run several existing tests with and without central config enabled
  (not exhaustive yet).

* Switch to ioutil.ReadFile for all types of agent persistence.

Fixes #6323
@jameshartig
Copy link
Contributor

jameshartig commented Sep 13, 2019

It looks like the docs say ?replace-existing-checks=1 but the code has:

query.Get("replace-existing-checks") == "" || query.Get("replace-existing-checks") == "true"

Should the docs be updated to say that the value should be =true or should =1 be allowed?

Also, how might this be added to the api go client? It looks like Agent.ServiceRegister does:

r := a.c.newRequest("PUT", "/v1/agent/service/register")

Can this be an option that's passed in AgentServiceRegistration or does it need to be a query parameter?

@banks
Copy link
Member

banks commented Sep 17, 2019

@fastest963 thanks, well spotted it does look like we should at least update the docs and add this to the api package. I'll create a new issue so we can track it and not loose this update in the sea of stuff.

rboyer added a commit that referenced this pull request Sep 24, 2019
…th central config enabled

Also:

* Finished threading replaceExistingChecks setting (from GH-4905)
  through service manager.

* Respected the original configSource value that was used to register a
  service or a check when restoring persisted data.

* Run several existing tests with and without central config enabled
  (not exhaustive yet).

* Switch to ioutil.ReadFile for all types of agent persistence.
rboyer added a commit that referenced this pull request Sep 24, 2019
…th central config enabled (#6472)

Also:

* Finished threading replaceExistingChecks setting (from GH-4905)
  through service manager.

* Respected the original configSource value that was used to register a
  service or a check when restoring persisted data.

* Run several existing tests with and without central config enabled
  (not exhaustive yet).

* Switch to ioutil.ReadFile for all types of agent persistence.
rboyer added a commit that referenced this pull request Sep 24, 2019
…th central config enabled (#6472)

Also:

* Finished threading replaceExistingChecks setting (from GH-4905)
  through service manager.

* Respected the original configSource value that was used to register a
  service or a check when restoring persisted data.

* Run several existing tests with and without central config enabled
  (not exhaustive yet).

* Switch to ioutil.ReadFile for all types of agent persistence.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-reply Waiting on response from Original Poster or another individual in the thread
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants