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

Resources for Custom TLS and Platform TLS products #364

Merged
merged 29 commits into from
Feb 17, 2021

Conversation

bengesoff
Copy link
Contributor

4 new resources:

  • fastly_tls_private_key
  • fastly_tls_certificate
  • fastly_tls_platform_certificate
  • fastly_tls_activation

10 new data sources

  • fastly_tls_activation
  • fastly_tls_activation_ids
  • fastly_tls_certificate
  • fastly_tls_certificate_ids
  • fastly_tls_configuration
  • fastly_tls_configuration_ids
  • fastly_tls_platform_certificate
  • fastly_tls_platform_certificate_ids
  • fastly_tls_private_key
  • fastly_tls_private_key_ids

This PR depends on the related go-fastly SDK PR (fastly/go-fastly#259) and will need its go.mod updating once it gets merged. (Currently uses a replace directive to point to the OC fork).

The documentation has been updated to use the new format, thanks to the upstream PRs #356 and #362. This carries with it the same caveats as noted elsewhere with regards to the generated documentation for nested schemas.

There were a few tweaks added on top of the docs generation script. In particular I added some logic to the Makefile to install tfplugindocs to a project-local ./bin directory due to the volatility in the generated documentation. I also removed the module caching from the github workflow because the tool was installed from the vendor directory which was already inside the git repo.

The Makefile had a command added for sweepers as well.

bengesoff and others added 24 commits February 8, 2021 12:30
Also add sweepers for TLS certificates and private keys to easily clean up resources leaked during any failed tests.
Terraform testing style guide seems to suggest camel case is used for
the main test name then an underscore separates different variations of
it.
Main changes were moving docs generation to tfplugindocs, and updating
the go-fastly SDK to v3. I added some changes to the upstream docs
generation to avoid having to globally install tfplugindocs. This was
also done upstream so I had to do some large merge conflict resolution
in this commit to combine the similar but different updates.

One commit message related to vendoring tfplugindocs was:

> Don't cache dependencies in github PR workflow, instead rely on /vendor
>
> Including the tfplugindocs module in vendor means it's updating with `go
> mod vendor` along with the other libraries used. When running `go
> install`, this vendored copy is used, and installed to a project-local
> /bin directory. This enables the version of tfplugindocs used to be
> independent of other go projects installed on one's system.
>
> This change means `make dependencies` is no longer used, and isn't
> needed in the github PR workflow. Furthermore, the source code for the
> tool is included in the /vendor already so the caching of ~/go/* isn't
> required either.
A couple naming/structure things resulting from different people writing the code. Have just tidied them up before PRing.
…#353)

* Add TLSCLientCert and TLSClientKey options for splunk logging

* Add some comments to clarify the usage splunk test tls cert values

* Update fastly/block_fastly_service_v1_splunk_test.go

* Update fastly/block_fastly_service_v1_splunk_test.go

* Update fastly/block_fastly_service_v1_splunk_test.go

* Update fastly/block_fastly_service_v1_splunk_test.go

* Update fastly/block_fastly_service_v1_splunk_test.go

* Update fastly/block_fastly_service_v1_splunk_test.go

* Update fastly/block_fastly_service_v1_splunk_test.go

Co-authored-by: Mark McDonnell <Integralist@users.noreply.github.com>
fastly/validators.go Outdated Show resolved Hide resolved
go.mod Outdated Show resolved Hide resolved
- **updated_at** (String) Timestamp (GMT) when the configuration was last updated.

<a id="nestedatt--dns_records"></a>
### Nested Schema for `dns_records`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same issue as @Integralist raised previously (hashicorp/terraform-plugin-docs#28) - no description on nested schema. I've left it autogenerated because I didn't think the descriptions were too critical, it is reasonably self-explanatory what the fields are for, and it seemed easier to maintain by leaving it autogenerated with the rest of the docs.

The intermediates_blob field of the fastly_tls_platform_certificate
resource can contain PEM blocks representing an arbitrary length chain
of certificates. The validation function for this field has been updated
to reflect this. It now loops through the provided string and checks
that each block it finds matches the expected block type until it
reaches the end of the string. Similarly the validation function for one
single block has been updated to fail if the string contains more than
one PEM block.
Was only used in creation function but should have also been used
in update too.
Also removed the `replace` directive in the go.mod to remove dependency
on opencredo fork.
Copy link
Collaborator

@Integralist Integralist left a comment

Choose a reason for hiding this comment

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

@bengesoff this PR looks great! I've left some questions and minor suggestions. Let me know your thoughts when you get a chance.

scripts/generate-docs.go Show resolved Hide resolved
@@ -74,6 +74,46 @@ func main() {
name: "ip_ranges",
path: tempDir + "/data-sources/ip_ranges.md.tmpl",
},
{
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be nice now that I think about it for these slices to be dynamically populated rather than having to remember to update the script every time a new resource is added.

Copy link
Collaborator

Choose a reason for hiding this comment

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

But I wouldn't worry too much about it for this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that could be a nice enhancement - scanning the directories or something

Comment on lines -55 to -73
- name: Restore cached binaries
id: cache
uses: actions/cache@v2
with:
path: ~/go/bin
key: ${{ runner.os }}-go-bin-${{ hashFiles('**/go.sum') }}
restore-keys: |
${{ runner.os }}-go-bin-
- name: Restore cached modules dependencies
uses: actions/cache@v2
with:
path: ~/go/pkg/mod
key: ${{ runner.os }}-go-mod-${{ hashFiles('**/go.sum') }}
restore-keys: |
${{ runner.os }}-go-mod-
- name: Install dependencies
if: steps.cache.outputs.cache-hit != 'true'
run: make dependencies
shell: bash
Copy link
Collaborator

Choose a reason for hiding this comment

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

Any explanation you can give me for why these segments of the workflow have been deleted?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes this change tied in with some of the other changes relating to the way tfplugindocs was being installed. I think previously the makefile was installing the package to GOROOT (i.e. ~/go/pkg and ~/go/bin), which would explain the steps in the workflow caching these directories.

However when adapting the upstream docs generation changes I found that the output of the tfplugindocs tool was quite volatile, given its alpha status, and thought it made sense to use the vendor style dependency management to pin in the exact version of the source code used to generate the docs and reduce disparity between all of the contributor's versions of it. In a similar vein I changed it to install the binary to a project-local ./bin directory to isolate it in case other terraform plugin projects were using different versions of it on anyone's machine. (I think you also made some very similar changes in parallel, e.g. adding a tools.go to allow go mod to find it, so I ended up merging my tweaks into that as well).

Anyway long story short, with the source code being installed to ./vendor and the compiled tfplugindocs binary being installed to ./bin, I didn't see a need to manually cache the external global GOROOT directories as the GitHub workflow does. (Also it had stopped working for me when I removed the make dependencies target, so I had to fix it somehow! 😉)

Does this make sense do you think? Happy to jump on a call and discuss it further if you think that would be helpful

Copy link
Collaborator

Choose a reason for hiding this comment

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

No that's fine. Thanks for the background information 👍🏻

.gitignore Outdated Show resolved Hide resolved

install-tools: dependencies
BIN=$(CURDIR)/bin
$(BIN)/%:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this need to be a dynamic target? Could the target still be named install-tools and generate-docs to reference it? My thinking is that in the updated generate-docs we're still adding $BIN to $PATH so the go install'ed tools will still be located there.

I feel like the dynamic target name (and specifically setting $(BIN)/tfplugindocs) is too much generalization without any real value? Although I could be mis-understanding the purpose for this refactor entirely.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was related to the same change as explained in the comment on .github/workflows/pr.yml. As part of moving the installation of tfplugindocs to be inside the terraform-provider-fastly directory, I used the non-PHONY target to avoid needing to re-run it every time, if the binary already exists. By extension, the dynamic target seemed useful in case other dependencies were added, given that the grep/awk command was already capable of installing the whole tools.go file.

That's the rationale anyway - I'm happy to change it to use a PHONY install-tools target if you'd prefer, and if I'm not mistaken that would rebuild the tool on each invocation, which could be helpful if it were upgraded? That's assuming that you agree installing to a project-local terraform-provider-fastly/bin directory is a good idea anyway, which you might not - also ok!

Copy link
Collaborator

Choose a reason for hiding this comment

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

OK that makes sense. I think avoiding reinstalling the tool every time is better any way and we can suffer not being on the bleeding edge all the time.

Steps: []resource.TestStep{
{
Config: testAccFastlyAccDataSourceTLSConfigurationIDs,
Check: resource.TestCheckResourceAttrSet("data.fastly_tls_configuration_ids.subject", "ids.#"),
Copy link
Collaborator

Choose a reason for hiding this comment

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

I presume this is just validating that there are zero elements within the ids list, is my understanding correct?

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 think it's just validating that the ids field has an attribute for its length and therefore loaded without error, not that it is specifically zero. There's not really anything interesting to test here because we don't know what configurations, if any, might be present and we can't create one and look for it, as we do in the other resources (eg activations)

fastly/provider.go Outdated Show resolved Hide resolved
fastly/data_source_fastly_tls_private_key_ids.go Outdated Show resolved Hide resolved
fastly/data_source_fastly_tls_private_key.go Outdated Show resolved Hide resolved
fastly/resource_fastly_tls_activation_test.go Outdated Show resolved Hide resolved
- removal of unneeded .gitignore entry
- removal of superfluous whitespace in docs example block
- conversion of TypeList to TypeSet in plural data sources' `ids` field
- a couple typo fixes here and there
- removal of Set function for controlling set hashing, unneeded
- consolidation of function naming to include "Fastly" before resource
  name
- fix some acctest.RandomWithPrefix with duplicate prefix
- clarify some comments
- add some checks in testAcc.*Exists functions when accessing the map of
  resources in state to avoid a panic if resource not found
@bengesoff
Copy link
Contributor Author

@Integralist I have fixed&resolved some comments, and replied to the rest. Thanks for the feedback, caught some things that had slipped through and raised some good points!

Add a -tfplugindocsPath command line argument to the parsing script to
make it a bit more robust than dynamically setting the PATH variable in
the Makefile. Defaults to local bin, as the Makefile expects, but I
still set the argument in the Makefile in case someone modifies the BIN
variable.
Copy link
Collaborator

@Integralist Integralist left a comment

Choose a reason for hiding this comment

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

@bengesoff LGTM.

I'll get this merged and then if you could let me know once you've rebased the latest master into your #365 PR.

Thanks!

@Integralist Integralist merged commit 748a103 into fastly:master Feb 17, 2021
@Integralist Integralist added the enhancement New feature or request label Feb 18, 2021
@trentrosenbaum trentrosenbaum deleted the tls-platform-and-custom branch March 15, 2021 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants