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

Fix/smart records merge on create #52

Merged
merged 10 commits into from
Jul 23, 2021
Merged

Conversation

ifree92
Copy link
Contributor

@ifree92 ifree92 commented Jul 16, 2021

No description provided.

ifree92 added 4 commits July 15, 2021 18:58
When user creates a resource with the records that already exist, the creating process should correctly merge it without duplicates

Signed-off-by: Ihor Levchenko <[email protected]>
Also commit contains:
- improved errors handling
- resolved an error upon generating a plan

Signed-off-by: Ihor Levchenko <[email protected]>
Copy link
Contributor

@StyleT StyleT left a comment

Choose a reason for hiding this comment

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

Let's cover existing code with some basic tests & merge this PR with tests that are covering the issue.

@@ -60,3 +60,5 @@ resource "namecheap_domain_records" "my-domain2-com" {
- `type` - (Required) Possible values: A, AAAA, ALIAS, CAA, CNAME, MX, MXE, NS, TXT, URL, URL301, FRAME
- `mx_pref` - (Optional) MX preference for host. Applicable for MX records only
- `ttl` - (Optional) Time to live for all record types. Possible values: any value between 60 to 60000

~> It is strongly recommended to set `address` and `hostname` in lower case to prevent undefined behavior!
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we always convert them to lowercase automatically during comparison?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically, yes.
However, the existing behavior works in the way where if a user changes the camel case of the address of any record, the provider will "re-create" the record. I will have to make the READ smarter.

I will revert on this in the context of a current PR.

@@ -34,6 +34,9 @@ The same workflow works for both: `record` items and `nameservers`.

-> This is the default behavior, however, we recommend to set the mode explicitly.

~> Upon creating a new resource with the records or nameservers that already exist, the provider will throw a duplicate
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need to add that it happens if subdomain & record type match

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Noted. I will check this.
At the moment, we have duplicates comparison only by hostname (subdomain), type, and address.

However, user allowed to create "mistakes" like:

resource "namecheap_domain_records" "domain" {
   #...
   record {
     hostname = "dev"
     type = "A"
     address = "11.22.33.44"
   }

   record {
     hostname = "dev"
     type = "A"
     address = "33.33.33.33"
   }
}

I will amend this behavior (and provide tests for all cases! 😆 )

@ifree92 ifree92 force-pushed the fix/smartRecordsMergeOnCreate branch 18 times, most recently from b282dea to 5a3ce90 Compare July 22, 2021 06:09
@ifree92 ifree92 force-pushed the fix/smartRecordsMergeOnCreate branch from 5a3ce90 to b8c448a Compare July 22, 2021 10:22
@ifree92 ifree92 force-pushed the fix/smartRecordsMergeOnCreate branch from b8c448a to b7c8471 Compare July 22, 2021 13:46
Signed-off-by: Ihor Levchenko <[email protected]>
source go-env.sh
make testacc
env:
NAMECHEAP_USER_NAME: ${{ secrets.NAMECHEAP_USER_NAME }}
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's move "non-secret" var values to this file. It will simplify debugging

@ifree92 ifree92 force-pushed the fix/smartRecordsMergeOnCreate branch 2 times, most recently from 4f0bb25 to f56564c Compare July 23, 2021 09:38
@ifree92 ifree92 force-pushed the fix/smartRecordsMergeOnCreate branch from f56564c to 68b3406 Compare July 23, 2021 09:44
@ifree92 ifree92 merged commit 6aa61c4 into master Jul 23, 2021
@ifree92 ifree92 deleted the fix/smartRecordsMergeOnCreate branch July 23, 2021 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants