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 Additional Upstream Server Parameters #30

Merged
merged 1 commit into from
Sep 5, 2019

Conversation

bvighnesha
Copy link

@bvighnesha bvighnesha commented Aug 26, 2019

Fixes #28

Proposed changes

Extend the go client to support additional parameters in upstream servers:

route
backup
down
drain
weight
service

Make sure that when adding an upstream server with unspecified parameters, the values of those parameters in NGINX Plus API are set with their default values.

Checklist

Before creating a PR, run through this checklist and mark each as complete.

  • I have read the CONTRIBUTING doc
  • I have added tests that prove my fix is effective or that my feature works
  • I have checked that all unit tests pass after adding my changes
  • I have updated necessary documentation
  • I have rebased my branch onto master
  • I will ensure my PR is targeting the master branch and pulling from my branch from my own fork

@bvighnesha bvighnesha self-assigned this Aug 26, 2019
@bvighnesha bvighnesha added the enhancement Pull requests for new features/feature enhancements label Aug 26, 2019
@bvighnesha bvighnesha force-pushed the Support_Additional_Upstream_Server_Parameters branch from 8151889 to e68bf3a Compare August 29, 2019 06:56
@bvighnesha bvighnesha requested a review from Rulox August 29, 2019 09:13
Copy link
Contributor

@Dean-Coakley Dean-Coakley left a comment

Choose a reason for hiding this comment

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

Please add unit test coverage for all new Upstream Server parameters added in this PR.

Please note the use of omitempty should only be used where a default must be set from the nplus api. Otherwise I don't think omitempty should be used.

Copy link

@Rulox Rulox left a comment

Choose a reason for hiding this comment

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

Looks good. Apart from adding tests as @Dean-Coakley suggested, I think the following:

Backup      bool   `json:"backup,omitempty"`
Down        bool   `json:"down,omitempty"`
Drain       bool   `json:"drain,omitempty"`

should be pointers.

The reason is, if you use omitempty in Go with a bool. If the user sets that bool to False the JSON will skip that field, and we can't really do that. Changing those to *bool will make the difference, because now empty is nil and true/false can be valid options if the user wants to fill that.

Does this make sense ?

PS: Alternatively you could remove the omitempty which is what you did I think, because those parameters are false by default.

@Rulox Rulox requested a review from pleshakov August 29, 2019 13:15
@pleshakov
Copy link
Contributor

pleshakov commented Aug 30, 2019

Regarding omitempty for new booleans, agree with @Rulox , better to remove omitempty from those.
In the TestStreamUpstreamServer and TestUpstreamServer for new boolean parameters, I suggest using true. Note that we already use false for them in TestUpstreamServerDefaultParameters and TestStreamUpstreamServerDefaultParameters

Update:
With the drain parameter is it a bit tricky. You can only start draining an existing upstream server. As a result, you cannot add an upstream server with drain: true. You can only patch an existing upstream server with drain: true.
Note that drain: false is always illegal value.
That's why for drain field, it is correct to use omitempty. However, we need to add a special test for drain when we set drain to true for an existing upstream server and then check that the field was set.

tests/client_test.go Outdated Show resolved Hide resolved
tests/client_test.go Show resolved Hide resolved
tests/client_test.go Outdated Show resolved Hide resolved
tests/client_test.go Show resolved Hide resolved
Copy link
Contributor

@Dean-Coakley Dean-Coakley left a comment

Choose a reason for hiding this comment

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

Looks good to me now!

Copy link

@Rulox Rulox left a comment

Choose a reason for hiding this comment

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

Looks good to me, I think we can add Service tests if we use the test.conf that already uses a resolver. Let me know what you think.

Copy link
Contributor

@pleshakov pleshakov left a comment

Choose a reason for hiding this comment

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

@b-v-r Please see my comments.

@Rulox re #30 (review) , not sure if it is worth doing. For a proper test, in addition to the resolver in the config, we will have to have a resolver that returns something for a DNS query.

servers[0].Drain = true

// Updating existing upstream server with drain directive
_, _, err = c.UpdateHTTPServers(upstream, servers)
Copy link
Contributor

Choose a reason for hiding this comment

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

UpdateHTTPServers doesn't update the existing upstream server - it can only add or delete, but not update. As a result, this test is not meaningful.

If we want to have a proper test, the client needs to have a method that updates an existing server. This method will send a PATCH request to the API http://nginx.org/en/docs/http/ngx_http_api_module.html#http_upstreams_http_upstream_name_servers_http_upstream_server_id to update an upstream server. However, this should not be in the scope of this tasks. For one thing, that new method will require new tests as well.

To fix this test, I suggest the following:

  1. Add a test upstream to test.conf:
upstream test-drain {
    zone test-drain 64k;

    server 127.0.0.1:9001 drain;
}
  1. Change the test so that:
    a. the test gets the servers of that upstreams
    b. it checks that the number of upstream servers is 1
    c. it compares the upstream server with the expected. The expected should have drain = true.

This way the updated test checks that if the drain is set to true in the API, the client will see the same value in the API response. However, it doesn't check that the client can set drain true, because of the mentioned limitation above.

@Rulox
Copy link

Rulox commented Sep 4, 2019

Yeah I was thinking of that too @pleshakov
Makes sense. @b-v-r testing service is not required as you first mentioned, sorry about this!

Copy link
Contributor

@pleshakov pleshakov left a comment

Choose a reason for hiding this comment

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

👍

@bvighnesha bvighnesha force-pushed the Support_Additional_Upstream_Server_Parameters branch from 8d423dc to 9333b5a Compare September 5, 2019 02:55
@bvighnesha bvighnesha merged commit 9a5eb22 into master Sep 5, 2019
@Rulox Rulox deleted the Support_Additional_Upstream_Server_Parameters branch September 26, 2019 17:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Pull requests for new features/feature enhancements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add backup to UpstreamServer
4 participants