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

advancedtls: add examples for reloading from file system #3976

Merged
merged 5 commits into from
Oct 27, 2020

Conversation

ZhenLian
Copy link
Contributor

@ZhenLian ZhenLian commented Oct 22, 2020

This PR adds an example in advancedtls on how to reload credentials from file system.

@easwars
Copy link
Contributor

easwars commented Oct 22, 2020

Could you please hold off on this until #3981 gets in. Thanks.

A very common way to achieve this is to reload from files.

In this example, users will need to provide a set of locations on the file system holding the credential data.
Once the credential data needs to be updated, users just need to change the credential data in the file system, and gRPC will pick up the changes automatically.
Copy link
Contributor

Choose a reason for hiding this comment

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

The client is making a single connection to the server. Given that established connections are not affected by change in the files being watched, how does this example demonstrate the credential reloading feature?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Gotcha. I understand your concern. I think the purpose of this example is to demonstrate how to set the API. The credential reloading feature is covered in advancedtls_integration_test, which reloads credentials in temp files.
This example is needed by that internal project, which will have a link pointed to this example in their user guide. The original sample code they gave me also didn't include the reloading feature.
I think the current wordings in README is a bit confusing. I've updated some text. Could you please take a look? Thank you so much!

@@ -0,0 +1,129 @@
#!/bin/bash
Copy link
Contributor

Choose a reason for hiding this comment

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

I can barely read bash. Please ask someone else to take a look at this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't, either :) @dfawley Could you please take a look at this please?
This is just a simple copy from https://github.com/grpc/grpc-go/blob/master/examples/examples_test.sh, with the following minor modifications:

  1. put the right test name and output in EXAMPLES, EXPECTED_SERVER_OUTPUT, and EXPECTED_CLIENT_OUTPUT
  2. replace cd ./examples with cd ./security/advancedtls/examples
  3. add a sleep 2s at the time after we start the server and before we initiate the client request(I added this mainly because otherwise, the test could sometimes fail locally with a server unavailable error. I didn't try on Travis, but when I ran other tests in main grpc it would sometimes fail as well. I am guessing my machine is a bit old that sometimes the server code needs more time to boot up)

Copy link
Member

Choose a reason for hiding this comment

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

add a sleep 2s at the time after we start the server and before we initiate the client request(I added this mainly because otherwise, the test could sometimes fail locally with a server unavailable error. I didn't try on Travis, but when I ran other tests in main grpc it would sometimes fail as well. I am guessing my machine is a bit old that sometimes the server code needs more time to boot up)

That seems strange. Do you see these errors when running the other examples_test.sh? If the client sends wait-for-ready RPCs then you shouldn't need to worry about this at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, it turned out that the tests failed in other examples_test.sh was due to a port is already used on my machine, instead of the unavailable error. So I think other scripts are good.
Just to confirm, the way to send wait-for-ready RPCs is through grpc.WithBlock(), right? I've updated that, removed the 2s sleep time, and ran the script for 100 times. No errors anymore.
Could you please check if the script make sense now?

Copy link
Member

Choose a reason for hiding this comment

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

Just to confirm, the way to send wait-for-ready RPCs is through grpc.WithBlock(), right? I've updated that, removed the 2s sleep time, and ran the script for 100 times. No errors anymore.

No, WithBlock makes Dial wait until there is a ready connection. WaitForReady means the RPC will wait until the channel is ready (however long and after however many failures that takes) before sending the RPC. It shouldn't be necessary, but if you are seeing weird failures due to connectivity, it can help. WithBlock also shouldn't be necessary; I'd remove it unless you can explain why it fixes things.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, sure. I've changed to WaitForReady and it also works. Please take a look, thank you so much!

Copy link
Member

Choose a reason for hiding this comment

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

OH, I thought you wouldn't need WFR either, as both of these options are actually unusual. But I see there is a race at startup here: if the client Dials before the server is Listening, then it will get an error. In this case, either WithBlock or WFR RPCs should be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great! Thanks for the confirmation!

Copy link
Contributor

@easwars easwars left a comment

Choose a reason for hiding this comment

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

The example client and server look good to me. Please also get approval for the bash changes. Thanks.

Also do you think you can add a TODO somewhere (either in the code or in the readme) that this example needs to be updated once #3981 gets in. Again, I'm a little concerned about asking someone to use this example which is going to change very quickly. At least it needs to be clearly communicated to them.

// Default timeout for normal connections.
defaultConnTimeout = 5 * time.Second
// Intervals that set to monitor the credential updates.
credRefreshingInterval = 200 * time.Millisecond
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this have to be this low? Or at least add a comment saying this is set to an impractically low value just for this example, and that in real use cases, this should be in the order of minutes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good! It doesn't need to be this low. I've updated it to 1 minute.

@easwars easwars assigned ZhenLian and unassigned easwars Oct 23, 2020
@ZhenLian ZhenLian requested a review from dfawley October 23, 2020 22:17
@ZhenLian
Copy link
Contributor Author

@easwars Sounds good. I've added some TODOs here. The other team said they would need the example in a "preview" state, and they've made it clear that things in their user guide could change. So I think it should be fine here.

@ZhenLian
Copy link
Contributor Author

@easwars @dfawley Thanks a lot for the review! Merging now...

@ZhenLian ZhenLian merged commit 829af01 into grpc:master Oct 27, 2020
davidkhala pushed a commit to Hyperledger-TWGC/grpc that referenced this pull request Dec 7, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 25, 2021
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.

None yet

3 participants