Giter Site home page Giter Site logo

vinyldns / terraform-provider-vinyldns Goto Github PK

View Code? Open in Web Editor NEW
14.0 14.0 16.0 345 KB

A Terraform provider for VinylDNS

Home Page: https://vinyldns.github.io/terraform-provider-vinyldns

License: Apache License 2.0

Makefile 3.49% HCL 1.02% Go 95.49%
dns hacktoberfest terraform terraform-provider vinyldns

terraform-provider-vinyldns's Introduction

VinylDNS Release VinylDNS API Docker Image VinylDNS Portal Docker Image

VinylDNS

VinylDNS

VinylDNS is a vendor-agnostic front-end for enabling self-service DNS and streamlining DNS operations. VinylDNS manages millions of DNS records supporting thousands of engineers in production at Comcast. The platform provides fine-grained access controls, auditing of all changes, a self-service user interface, secure RESTful API, and integration with infrastructure automation tools like Ansible and Terraform. It is designed to integrate with your existing DNS infrastructure, and provides extensibility to fit your installation.

VinylDNS helps secure DNS management via:

  • AWS Sig4 signing of all messages to ensure that the message that was sent was not altered in transit
  • Throttling of DNS updates to rate limit concurrent updates against your DNS systems
  • Encrypting user secrets and TSIG keys at rest and in-transit
  • Recording every change made to DNS records and zones

Integration is simple with first-class language support including:

  • Java
  • Python
  • Go
  • JavaScript

Table of Contents

Quickstart

Docker images for VinylDNS live on Docker Hub at https://hub.docker.com/u/vinyldns/. To start up a local instance of VinylDNS on your machine with docker:

  1. Ensure that you have docker and docker-compose
  2. Clone the repo: git clone https://github.com/vinyldns/vinyldns.git
  3. Navigate to repo: cd vinyldns
  4. Run ./quickstart/quickstart-vinyldns.sh. This will start up the api at localhost:9000 and the portal at localhost:9001
  5. See Things to Try in the Portal for getting familiar with the Portal
  6. To stop the local setup, run ./utils/clean-vinyldns-containers.sh.

There exist several clients at https://github.com/vinyldns that can be used to make API requests, using the endpoint http://localhost:9000.

Quickstart Optimization

If you are experimenting with Quickstart, you may encounter a delay each time you run it. This is because the API and Portal are rebuilt every time you launch Quickstart. If you'd like to cache the builds of the API and Portal, you may want to first run:

Script Description
build/assemble_api.sh This will create the API jar file which will then be used by Quickstart
build/assemble_portal.sh This will create the Portal zip file which will then be used by Quickstart

Once these scripts are run, the artifacts are placed into the artifacts/ directory and will be reused for each Quickstart launch. If you'd like to regenerate the artifacts, simply delete them and rerun the scripts above.

Things to Try in the Portal

  1. View the portal at http://localhost:9001 in a web browser
  2. Login with the credentials professor and professor
  3. Navigate to the groups tab: http://localhost:9001/groups
  4. Click on the New Group button and create a new group, the group id is the uuid in the url after you view the group
  5. Connect a zone by going to the zones tab: http://localhost:9001/zones.
    1. Click the -> Connect button
    2. For Zone Name enter ok with an email of [email protected]
    3. For Admin Group, choose a group you created from the previous step
    4. Leave everything else as-is and click the Connect button at the bottom of the form
  6. A new zone ok should appear in your My Zones tab (you may need to refresh your browser)
  7. You will see that some records are preloaded in the zone already, this is because these records are preloaded in the local docker DNS server and VinylDNS automatically syncs records with the backend DNS server upon zone connection
  8. From here, you can create DNS record sets in the Manage Records tab, and manage zone settings and ACL rules in the Manage Zone tab
  9. To try creating a DNS record, click on the Create Record Set button under Records, Record Type = A, Record Name = my-test-a, TTL = 300, IP Addressess = 1.1.1.1
  10. Click on the Refresh button under Records, you should see your new record created

Verifying Your Changes

VinylDNS will synchronize with the DNS backend. For the Quickstart this should be running on port 19001 on localhost .

To verify your changes, you can use a DNS resolution utility like dig

$ dig @127.0.0.1 -p 19001 +short my-test-a.ok
1.1.1.1

This tells dig to use 127.0.0.1 as the resolver on port 19001. The +short just makes the output a bit less verbose. Finally, the record we're looking up is my-test-a.ok. You can see the returned output of 1.1.1.1 matches the record data we entered.

Other things to note

  1. Upon connecting to a zone for the first time, a zone sync is executed to provide VinylDNS a copy of the records in the zone
  2. Changes made via VinylDNS are made against the DNS backend, you do not need to sync the zone further to push those changes out
  3. If changes to the zone are made outside of VinylDNS, then the zone will have to be re-synced to give VinylDNS a copy of those records
  4. If you wish to modify the url used in the creation process from http://localhost:9000, to say http://vinyldns.yourdomain.com:9000, you can modify the quickstart/.env file before execution.
  5. Further configuration can be ac https://www.vinyldns.io/operator/config-portal & https://www.vinyldns.io/operator/config-api

Code of Conduct

This project, and everyone participating in it, are governed by the VinylDNS Code Of Conduct. By participating, you agree to this Code.

Developer Guide

See DEVELOPER_GUIDE.md for instructions on setting up VinylDNS locally.

Contributing

See the Contributing Guide.

Maintainers and Contributors

The current maintainers (people who can merge pull requests) are:

See AUTHORS.md for the full list of contributors to VinylDNS.

See MAINTAINERS.md for documentation specific to maintainers

Credits

VinylDNS would not be possible without the help of many other pieces of open source software. Thank you open source world!

Given the Apache 2.0 license of VinylDNS, we specifically want to call out the following libraries and their corresponding licenses shown below.

terraform-provider-vinyldns's People

Contributors

britneywright avatar ctreatma avatar harrythehat1975 avatar iamjarvo avatar jhg03a avatar mdb avatar remerle avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-vinyldns's Issues

Apply fails when `zone_id` changes

Observed behavior: terraform apply fails when a record set's zone_id is changed.

Desired behavior: record set is deleted from old zone and created in new zone.

Additional observations: ForceNew is missing on the record set schema for the zone_id field.

vinyldns_record_set.status_dc1_record_set_v6: Modifying... (ID: 926f6d17-27a1-41b6-a572-76d292da070f)
  zone_id: "cf08aea3-c786-4f70-88c9-76ddce762e9c" => "d745691b-3529-4c9f-ac11-21121c92b4fc"
2019-05-20T20:11:48.058Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:48 [INFO] Updating vinyldns record set: 926f6d17-27a1-41b6-a572-76d292da070f
2019-05-20T20:11:48.203Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:48 [DEBUG] Waiting for state to become: [Complete]
2019-05-20T20:11:48.703Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:48 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:48.847Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:48 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:49.347Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:49 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:49.479Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:49 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:49.979Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:49 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:50.111Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:50 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:50.611Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:50 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:50.747Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:50 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:51.247Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:51 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:51.377Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:51 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:51.877Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:51 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:52.009Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:52 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:52.509Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:52 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:52.639Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:52 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:53.140Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:53 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:53.273Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:53 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:53.773Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:53 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:53.905Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:53 [TRACE] Waiting 500ms before next try
2019-05-20T20:11:54.405Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:54 [INFO] waiting for 926f6d17-27a1-41b6-a572-76d292da070f Complete status
2019-05-20T20:11:54.537Z [DEBUG] plugin.terraform-provider-vinyldns: 2019/05/20 20:11:54 [ERROR] record set status Failed: &errors.errorString{s:"record set status Failed"}
2019/05/20 20:11:54 [ERROR] root: eval: *terraform.EvalApplyPost, err: 1 error(s) occurred:

* vinyldns_record_set.status_dc1_record_set_v6: record set status Failed
2019/05/20 20:11:54 [ERROR] root: eval: *terraform.EvalSequence, err: 1 error(s) occurred:

* vinyldns_record_set.status_dc1_record_set_v6: record set status Failed

2019/05/20 20:11:54 [DEBUG] plugin: waiting for all plugin processes to complete...
Error: Error applying plan:

Support CRUD actions to records in shared zones

To make updates to records that live in a zone that is shared=true (See VinylDNS docs), it is necessary to use the batch change API endpoint, which terraform-provider-vinyldns does not currently do.

I can imagine a few approaches...

  1. Rather than shoehorn support for recordsets that live in shared zones into the current vinyldns_record_set model, maybe this warrants a vinyldns_batch_changes resource:
    https://www.vinyldns.io/api/batchchange-model.html

  2. Change vinyldns_record_set to use the batch changes API, perhaps always?

Members and Admins sections of state are not populated when a group is created

provider "vinyldns" {
}

resource "vinyldns_group" "admin_group" {
  name = "admin-group"
  email = "[email protected]"
}

After ^ is run successfully parts of admin and member are not saved in the state

 ~ vinyldns_group.admin_group
      admin.#:                     "1" => "0"
      admin.321395458.email:       "" => ""
      admin.321395458.first_name:  "" => ""
      admin.321395458.id:          "123" => ""
      admin.321395458.last_name:   "" => ""
      admin.321395458.user_name:   "" => ""
      member.#:                    "1" => "0"
      member.321395458.email:      "" => ""
      member.321395458.first_name: "" => ""
      member.321395458.id:         "123" => ""
      member.321395458.last_name:  "" => ""
      member.321395458.user_name:  "" => ""

Properly exercise zone 'transfer_connection' and 'zone_connection' during tests

In current implementation, the terraform-provider-vinyldns tests do not exercise the zone resource transfer_connection and zone_connection arguments. It would be useful to have zone tests like the existing ones that do not exercise these arguments as well as additional zone tests that do exercise these arguments.

Improve "read" methods to handle "resource does not exist" scenarios

In current implementation terraform-provider-vinyldns's various resource "read" methods will error if the VinylDNS API 404s. According to Terraform documentation...

If the ID is updated to blank, this tells Terraform the resource no longer exists (maybe it was destroyed out of band). Just like the destroy callback, the Read function should gracefully handle this case.

https://www.terraform.io/docs/extend/writing-custom-providers.html#implementing-read

Importing resources fails with a non descriptive error

When running a terraform import using what I believe to be the correct format the provider gives back the following error and the import fails.

Error: error reading recordset (c368d394-c1bc-4dd0-9b3a-16f589ffb4e8): Get /zones/<zone_id>/recordsets/<record_set_id>: unsupported protocol scheme ""

The command that was run was

terraform import -var-file=client.tfvars.json -var-file=backend.tfvars module.base.vinyldns_record_set.promxy-record-set <zond_id>:<record_set_Id>

Set custom UserAgent on `go-vinyldns` client

As a maintainer of terraform-provider-vinyldns, I'd like terraform-provider-vinyldns send a custom User-Agent on requests such that usage can be tracked in aggregated logs and operational visibility metrics. I'm imagining a UserAgent string such as terraform-provider-vinyldns/<version>.

Create import functionality

Currently, terraform-provider-vinyldns does not offer import functionality. I haven't researched this -- it's at least possible Terraform provides it by default. If it doesn't exist, we'll want to author it.

Vinyldns provider with Terraform v13

Im getting this error during the terraform v 12 to 13 upgrade :


Error while installing -/vinyldns: provider registry registry.terraform.io
does not have a provider named registry.terraform.io/-/vinyldns

Anyone come across this?

Fix build.sh

build.sh allows users to utilize Docker and docker-compose to build terraform-provider-vinyldns binaries without the need to establish a Golang dev environment. However, it seems the GNUMakefile has perhaps evolved a bit since its inception and it no longer works.

Add various Zone attributes

According to the VinylDNS zone model, it appears there are various Zone attributes not currently supported or computed by terraform-provider-vinyldns:

  • acl
  • latestSync
  • updated

Of the above, acl is likely the most important and useful, as this would allow users to set the access control rules governing the zone

Orchestrate a delete/recreate when users attempt to update a record set name

Currently, an attempt to update a record set's name results in the following from the VinylDNS API, as a name change requires a delete and fresh creation:

Error: Request URL:
...
Request Method:
PUT
Request body:
...
Response code: 
422
Response body:
"Cannot update RecordSet's name."

However, terraform-provider-vinyldns could perform the delete and fresh create on users' behalf. Is that worth considering?

properly handle group 'admin' and 'member'

In current implementation, I don't believe 'admin' and 'member' are properly stored in state. The tests pass, because 'admin' and 'member' are not currently exercised in the tests.

Create a Terraform 0.12.x compatible release

Currently, the latest available release is complied against a 0.11.x version of Terraform. When trying to upgrade to Terraform 0.12.x we are presented with the following error:
Error: failed to load provider “vinyldns”: Incompatible API version with plugin. Plugin version: 4, Client versions: [5]

The fix would be to release a version of the vinyldns provider which is complied against Terraform 0.12.x as it does not seem to want any non 0.12.x providers if you upgrade.

adopt SchemaVersion and StateUpgraders where relevant

It would be useful to consider the use of schema.Resource.SchemaVersion on terraform-provider-vinyldns resources such that schema.Resource.StateUpgraders could be leveraged to upgrade existing users' tfstate when schema semantics change such that users can easily adopt new versions of the provider.

More can be read here:

    // StateUpgraders contains the functions responsible for upgrading an
    // existing state with an old schema version to a newer schema. It is
    // called specifically by Terraform when the stored schema version is less
    // than the current SchemaVersion of the Resource.
    //
    // StateUpgraders map specific schema versions to a StateUpgrader
    // function. The registered versions are expected to be ordered,
    // consecutive values. The initial value may be greater than 0 to account
    // for legacy schemas that weren't recorded and can be handled by
    // MigrateState.
    StateUpgraders []StateUpgrader

Consider using goreleaser

Evidently, HashiCorp is considering recommending the use of goreleaser for managing provider releases. terraform-provider-vinyldns should perhaps consider its use.

Improve "destroy" methods to handle "resource does not exist" scenarios

In current implementation terraform-provider-vinyldns's various resource "destroy" methods will error if the VinylDNS API 404s. According to Terraform documentation...

The destroy function should always handle the case where the resource might already be destroyed (manually, for example). If the resource is already destroyed, this should not return an error. This allows Terraform users to manually delete resources without breaking Terraform.

https://www.terraform.io/docs/extend/writing-custom-providers.html#implementing-destroy

Non-idempotency on AAAA record-set

Steps to reproduce

  1. Terraform destroy (just to clean house)
  2. Terraform apply (all resources applied successfully)
  3. Terraform apply (Resource changes apply to remove extraneous brackets)

Diff example

# module.custommodule.vinyldns_record_set.dns_instance6[0] will be updated in-place
  ~ resource "vinyldns_record_set" "dns_instance6" {
        id               = "18b67c48-a348-4241-9fc9-9dff4c8235b4:82d3d9c6-acb6-43c0-a655-e81a0c7f252f"
        name             = "hostname"
      ~ record_addresses = [
          - "64:558:fc0a:3:f816:3eff:fed7:badd",
          + "[64:558:fc0a:3:f816:3eff:fed7:badd]",
        ]
        ttl              = 120
        type             = "AAAA"
        zone_id          = "18b67c48-a348-4241-9fc9-9dff4c8235b4"
    }

I don't see this with IPv4 A records. You can run terraform apply as much as you like and every time it thinks it needs to change the IP address. I'm guessing there's a missmatch between IPv6 formatting rules between the API and the TF provider. Found in releases TF11 + 0.9.4 & TF12 + 0.9.5.

Author unit tests

In current implementation, terraform-provider-vinyldns has Terraform-style acceptance tests, though no unit tests. It's arguably worth authoring various terraform-provider-vinyldns unit tests to validate the functionality of individual helper functions, etc.

Plan for Terraform Plugin SDK v1 end of life

The Terraform Plugin SDK is a framework that lets developers create and maintain Terraform providers. HashiCorp will be ending support for the version 1 release of the Plugin SDK on July 31, 2021. Users of the Terraform CLI and Terraform Cloud are not affected by this and do not need to take any action. Maintainers of Terraform providers who are impacted are encouraged to use our upgrade guide to move to version 2 of the Terraform Plugin SDK. Follow our tutorials to develop your first provider. Additional information can be found in the Terraform Provider Developer Community Discuss forum: End of Life Timeline for v1 of the Terraform Plugin SDK.

More info: https://www.hashicorp.com/blog/announcing-hashicorp-terraform-1-0-general-availability

Support shared zones model

VinylDNS 0.9.0 has a "shared zones" model which will likely impact how terraform-provider-vinyldns works.

In particular, I believe it would be necessary to:

  • upgrade terraform-provider-vinyldns to use go-vinyldns 0.9+, which supports shared zones
  • factor into consideration RecordSet.OwnerGroupID on all record set actions -- this will need to be set and respected on all API transactions

It may also be beneficial to:

  • support import via issue #12
  • support data sources via issue #9
  • test how it looks/feels to 1) manage resources with VinylDNS 0.8 + terraform-provider-vinyldns 0.8 and then 2) observe how it looks/feels to mange those same resources -- with the same tfstate -- using VinylDNS 0.9 with terraform-provider-vinyldns 0.8. NOTE: this sounds kinda complex; I'm all ears if others have better opinions on how to tackle this.
  • test how it looks/feels to 1) manage resources with VinylDNS 0.8 + terraform-provider-vinyldns 0.8 and then 2) observe how it looks/feels to mange those same resources -- with the same tfstate -- using VinylDNS 0.9 with terraform-provider-vinyldns 0.9. NOTE: this sounds kinda complex; I'm all ears if others have better opinions on how to tackle this.

Support NS records

At present, terraform-provider-vinyldns does not support NS records, despite that the VinylDNS API does support NS records.

This is arguably a bug, as terraform-provider-vinyldns should ideally support all functionality offered by the VinylDNS API.

Run `bin/docker-up-vinyldns.sh` from a specific VinylDNS release branch

When running the make acceptance tests, currently terraform-provider-vinyldns starts a Dockerized VinylDNS API version via VinylDNS's bin/docker-up-vinyldns.sh script. It would be good to run this script from a specific VinylDNS branch version. While this is not the most elegant implementation, I'm imagining something like the following may still be an improvement, for example:

  if [ ! -d "$(GOPATH)/src/$(VINYLDNS_REPO)" ]; then \
    echo "$(VINYLDNS_REPO) not found in your GOPATH (necessary for acceptance tests), getting..."; \
    git clone \
      --branch v0.9.1 \
      https://$(VINYLDNS_REPO) \
      $(GOPATH)/src/$(VINYLDNS_REPO); \
  fi
  if [[ $(shell git --git-dir $(GOPATH)/src/$(VINYLDNS_REPO)/.git rev-parse HEAD)" != "12c6d4e67cf92d5be9801630155d640f55a38f51" ]]; then
    rm -rf $(GOPATH)/src/$(VINYLDNS_REPO);
    git clone \
      --branch v0.9.1 \
      https://$(VINYLDNS_REPO) \
      $(GOPATH)/src/$(VINYLDNS_REPO); \
  fi
  $(GOPATH)/src/$(VINYLDNS_REPO)/bin/docker-up-vinyldns.sh \
  --api-only \
  --version 0.9.1

provider fails to support txt records with multiple values

In current implementation terraform-provider-vinyldns fails to accommodate txt records with multiple text values. For example, VinylDNS accommodates A, but terraform-provider-vinyldns only handles B:

A

{
    "type": "TXT",
    "name": "foo",
    "records": [
        {
            "text": "baz"
        },
        {
            "text": "bim"
        }
    ],
}

B

{
    "type": "TXT",
    "name": "foo",
    "records": [
        {
            "text": "baz"
        }
    ],
}

Evolve release process to conform to Terraform registry standards

In order to conform to the standards recommended by registry.terraform.io, evidently each provider release must meet the following criteria:

There are 1 or more zip files containing the built provider binary for a single architecture.

The binary name is terraform-provider-{NAME}-{VERSION}.

Formatted as terraform-provider-{NAME}-{VERSION}-{OS}-{ARCH}.zip

It's recommended to build for all of these os/architecture pairs if possible:

  • darwin/amd64
  • freebsd/386
  • freebsd/amd64
  • freebsd/arm
  • linux/386
  • linux/amd64
  • linux/arm
  • linux/arm64
  • openbsd/386
  • openbsd/amd64
  • solaris/amd64
  • windows/386
  • windows/amd64

There is a terraform-provider-{NAME}-{VERSION}-SHASUMS file, which contains a sha256 sum for each zip file in the release.

shasum -a 256 *.zip > terraform-provider-{NAME}-{VERSION}-SHASUMS

There is a terraform-provider-{NAME}-{VERSION}-SHASUMS.sig file, which is a valid GPG signature of the terraform-provider-{NAME}-{VERSION}-SHASUMS file using the keypair.

gpg --detach-sign terraform-provider-{NAME}-{VERSION}-SHASUMS

Release is finalized (not a private draft).

Vinyldns fails to read record set when trying to fetch via Jenkins after converting from denis to vinyldns resource.

I tried to convert the denis resource to vinyldns resource in terraform since the newer version of terraform is not compatible with older vinyldns providers anymore and Jenkins has been throwing this error since then. The same works when i run locally without jenkins with the same credentials. Im using terraform-provider-vinyldns_v0.9.5 and terraform aws provider v2.68. Tried with various vinyl dns proveider versions from terraform-provider-vinyldns_v0.9.1 through terraform-provider-vinyldns_v0.9.5, its the same error.

Error: error reading recordset (xx-xx-xx-xx): Get https://api.vinyldns.comcast.net:9443/zones/xx-xx-xx-xx/recordsets/xx-xx-xx-xx: Forbidden

Anyone faced this ?

Build for HashiCorp-recommended OS/arch combos

Ideally, terraform-provider-vinyldns releases should be provided for the entire HashiCorp-recommended list of OS/arch combos:

darwin/amd64
freebsd/386
freebsd/amd64
freebsd/arm
linux/386
linux/amd64
linux/arm
linux/arm64
openbsd/386
openbsd/amd64
solaris/amd64
windows/386
windows/amd64

Provide HashiCorp with the public key for the GPG keypair that we will be signing releases with

In order to address issue #84 , we will also need to provide HashiCorp a GPG public key. All provider releases are required to be signed, thus you must provide HashiCorp with the public key for the GPG keypair that you will be signing releases with. The Terraform Registry will validate that the release is signed with this key when publishing each version, and Terraform will verify this during terraform init.

Export your public key in ASCII-armor format

gpg --armor --export {Key ID or email address}

`make website` fails to serve the docs

It appears that make website fails to serve the docs contained in the website directory at http://localhost:4567/docs/providers/vinyldns.

In creating the docs housed in the website directory, I followed the pattern of other github.com/terraform-providers, although it's unclear why make website fails to work for vinyldns/terraform-provider-vinyldns, despite working for other TF providers, such as terraform-provider-grafana.

Is it because of a typo? Is it because no symlink exists here? Is it because terraform-provider-vinyldns does not live in the github.com/terraform-providers org?

These questions warrant further research.

Docker build fails

When attempting to use the docker-compose build I experienced the following:

| => docker-compose build
Building build
Step 1/4 : FROM golang:1.10.3
 ---> d0e7a411e3da
Step 2/4 : COPY . /go/src/github.com/vinyldns/terraform-provider-vinyldns
 ---> Using cache
 ---> 46cc00f38a0d
Step 3/4 : WORKDIR /go/src/github.com/vinyldns/terraform-provider-vinyldns
 ---> Using cache
 ---> 122d439fb0b1
Step 4/4 : RUN make build
 ---> Running in 1efa0b417228
export CGO_ENABLED=0; gox -ldflags "-X main.version=0.8.0" -os "linux darwin windows" -arch "386 amd64" -output "build/{{.OS}}_{{.Arch}}/terraform-provider-vinyldns"
/bin/sh: 1: gox: not found
GNUmakefile:43: recipe for target 'build' failed
make: *** [build] Error 127
ERROR: Service 'build' failed to build: The command '/bin/sh -c make build' returned a non-zero code: 2```

This was against the head of master at commit 343dacb

Support shared zones in "vinyldns_zone" data source

Currently, terraform-provider-vinyldns's vinyldns_zone data source uses the get zone by name endpoint, which does not permit users to GET a zone unless the user is a member of the owner group.

However, the list zones endpoint could be used with the nameFilter param and the ignoreAccess=true param to successfully fetch details for shared zones.

Use ZonesListAll and RecordSetsListAll methods

In current implementation, terraform-provider-vinyldns uses RecordSets and Zones, which fail to handle pagination, name filters, and max items. This means terraform-provider-vinyldns will always fetch the first 100 zones or record sets, but fail to fetch additional zones or record sets in instances when there are more than 100. The ZonesListAll and RecordSetsListAll methods would address this. These methods can also be used to address issue #9

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.