Previously this was not checked so an existing record (e.g. with type A) would be overwritten on upsert by a record with the same name but different type (e.g. TXT).
This commit also:
* publicizes the type variable appending the underscore affix (required to maintain compatibility with CloudFormation which sets type as the CF type),
* fixes a wrong assumption in tests that UPSERT applies a change to Type (it creates a distinct record instead),
* Updates ACM model to use serial_number instead of deprecated and remove serial causing Travis failures.
AWS Route53 treats www.example.com (without a trailing dot)
and www.example.com. (with a trailing dot) as identical.
Hence, after creating a `www.example.com` record,
`www.example.com.` name is saved in Route53.
But moto treated `www.example.com` and `www.example.com.` as different.
This commit fixes the moto behavior.
According to AWS API reference and Boto documentation they are to begin the record listing from,
not for filtering. So their current behavior in moto is not consistent with AWS.
We will continue to store just the unique ID, but since the AWS API
returns /hostedzone/<id>, we should accept attempts to pass that back.
For example, both just the ID as well as /hostedzone/<id> work for
specifying the HostedZoneId of a ResourceRecordSet in CloudFormation. So
we should support that too.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
While there isn't an API method exposed for directly deleting a Route 53
RecordSet (it's performed via POST that acts more like a PATCH than
anything
else)[http://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html],
CloudFormation can have templates which contain RecordSets which refer
to zones that don't exist inside the template. Ergo, we need a way to
effect a delete upon these RecordSets when we don't have a direct
reference to the zone.
This exposes a delete method that isn't hooked up to any response (and
rightfully so), it just enables the ~polymorphic deletion behavior that
we've written into the CloudFormation implementation.
Signed-off-by: Scott Greene <scott.greene@getbraintree.com>
