My theory is that they were removed because they're always created the "first" time (from chef's view) using a CREATE - but of course NS and SOA records already exist in a zone.
That would return errors like this if you had tried to use SOA on an existing zone:
[2016-06-28T19:19:14-04:00] ERROR:
aws_route53_hosted_zone[test.example.com] (/hostedzone/ZLP41234PABS)
(roles::route53 line 23) had an error:
Aws::Route53::Errors::InvalidChangeBatch: Tried to create resource
record set [name='test.example.com.', type='SOA'] but it already
exists
The correct approach is to use UPSERT instead of CREATE for these.
It's not clear to me where to hook in "if SOA or NS and they already exist, use UPSERT" logic - but the easy solution is to always use UPSERT... not sure of the impact of doing that.
PR coming shortly for a workaround to add SOA and NS support back - use UPSERT instead of CREATE in all cases. I'd definitely be interested in a pro/con discussion of where UPSERT might be bad - but "it works for me" :)
keen99
commented
8 years ago
According to the code, SOA and NS records are supported:
attribute :type, equal_to: %w(SOA A TXT NS CNAME MX PTR SRV SPF AAAA), required: truehttps://github.com/chef/chef-provisioning-aws/blob/v1.10.0/lib/chef/resource/aws_route53_record_set.rb#L46
But if you try to use them you get useful errors like:
raise ArgumentError, "Argument '#{type}' must be one of #{%w(A MX SRV CNAME TXT PTR AAAA SPF)}"https://github.com/chef/chef-provisioning-aws/blob/v1.10.0/lib/chef/resource/aws_route53_record_set.rb#L46
Looking at history, SOA and NS were removed in https://github.com/chef/chef-provisioning-aws/commit/c4cc47903cf66e4d613f60ec5481792802318d7c with no specific explaination.
My theory is that they were removed because they're always created the "first" time (from chef's view) using a CREATE - but of course NS and SOA records already exist in a zone.
That would return errors like this if you had tried to use SOA on an existing zone:
The correct approach is to use UPSERT instead of CREATE for these.
It's not clear to me where to hook in "if SOA or NS and they already exist, use UPSERT" logic - but the easy solution is to always use UPSERT... not sure of the impact of doing that.
PR coming shortly for a workaround to add SOA and NS support back - use UPSERT instead of CREATE in all cases. I'd definitely be interested in a pro/con discussion of where UPSERT might be bad - but "it works for me" :)