-
Notifications
You must be signed in to change notification settings - Fork 129
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 support for Platform TLS #154
Conversation
supress lint, fix some names format the fixtures body properly according to a real test request minor fix
Co-Authored-By: Geoff Schorkopf <[email protected]>
e385251
to
3e701d0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @shreddedbacon, thank you for contributing this we really appreciate it.
Apologies for the large amount of requested changes, however you'll see that they all relate to the JSONAPI response format of this API and not problems with your code and should be easy to tweak.
I've only done a partial review of the PrivateKey
endpoints and have left the bulk cert methods, as most of my comments apply to both implementations. Let me know once you've had a chance to refactor or have any questions.
Thanks!
Brilliant, thanks. I will work through this and let you know when ready. |
Hi @phamann. I've adjusted my code to use the |
Hey guys! Great to see progress on the TLS API. I have been working on the "Non-Platform" TLS part and from what I see the Private Keys API is the same for "Regular TLS" and "Platform TLS". Would it make sense to give the key-related functions neutral names like If you like I could throw in my implementation of exactly that and a bit of JSONAPI paging and filtering on top. But I also don't want to get in the way of what you already did @shreddedbacon . |
I didn't know they were different. In that case it makes sense to name them a neutral name, in their own file. I'm happy to adjust my PR as I'm also currently using my branch to build out an operator for our platform. How far along is your work on "Regular TLS" @scheying ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the speedy changes to this, @shreddedbacon, I appreciate your patience here. It's looking much better! Most of my comments are minor comment style changes, some small copy/pasta errors and a question around using pointers for the pagination input structs.
My last major change request would be to update the tests to be more inline with the style we use in the package. Which would be: one TestClient_PlatformPrivateKey
function which creates a key (defers its deletion) then uses that to perform the other operations (list, update, delete), with each operation assert the properties or length returned are valid. We also have seperate functions to test the validations. An example of this style can be found in some of the recent PRs, such as users: https://github.com/fastly/go-fastly/blob/master/fastly/user_test.go#L19-L133
Hope that helps. After this last change set, we should be good to merge!
@scheying This is a great question and in theory makes sense to me. I'm afraid that I'm not an internal SME (subject-matter-expert) on our TLS APIs, so will get someone on that team to have a look and share their thoughts here. |
No problem at all. Thanks for your patience. Will adjust again! |
…atform-tls, added additional tests to suit test styling and additional description updates
…lter actually work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 LGTM
Thank you for all of your work and promptness on this PR @shreddedbacon really appreciated. I'll double check that the TLS team are happy, but should get it merged and released ASAP.
Hi again @phamann For the filters to actually work, I had to add the header
As described in the API documentation https://docs.fastly.com/api/platform-tls#tls_bulk_certificates_81cc5acbf847f71ecd4068ed58bfc5c5 When I remove this header, the filter no longer works. Is there something I'm missing here? I noticed a few other functions use filters and have the same |
@shreddedbacon You're not missing anything here. This is another nuance of our JSONAPI API requests and not your implementation. For those requests you are using the |
Awesome. Thanks for smashing through this with me, appreciate it! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really great; thank you so much for your contribution to this library!
fastly/platform_tls.go
Outdated
// `tls_domains.id` filter seems to work where `tls_domain.id` does not, documentation wrong? | ||
// https://docs.fastly.com/api/platform-tls#tls_bulk_certificates_81cc5acbf847f71ecd4068ed58bfc5c5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both filtering parameters should be supported, with a preference for the plural. I'll follow up with the appropriate teams.
e5c57cd
to
745bc1e
Compare
Hi @thommahoney. |
Looking good! Once again thank you for your contribution 👍 I'll let you know once released. |
This was released in v1.10.0 🎉 |
Looking to add support for Platform TLS
For the test process described here, I wasn't sure how to actually do this with Platform TLS.
I don't appear have the ability to create new TLS configuration IDs to have one to use as a dummy, and I am unsure if doing anything here will have any cost implications.