Closed leslitagordita closed 5 years ago
As mentioned, the LinodeGo wrapper will need support for UpdateIPAddress
.
I'm thinking the resource would be linode_rdns
, and it would take a name and a list of IP addresses.
// hypothetical resource - it may not be possible, or efficient, to discover all of the addresses associated with a RDNS name.
// If this approach was taken, address would need to be a TypeSet to avoid the ordering problems of TypeList
resource "linode_rdns" "www" {
rdns = "www.example.com"
addresses = [ "${linode_instance.www.ip_address}", "${linode_instance.www.ipv6}" ]
}
or perhaps
// hypothetical resource - closely aligns to the RDNS API endpoint fields. One address per resource.
resource "linode_rdns" "www" {
rdns = "www.example.com"
address = "${linode_instance.www.ip_address}"
}
resource "linode_rdns" "www-v6" {
rdns = "www.example.com"
address = "${linode_instance.www.ipv6}"
}
or perhaps
// hypothetical resource - Two fields to represent the two addresses a Linode typically has. This is weak because there may still be a need for additional addresses to be use the same RDNS name
resource "linode_rdns" "www" {
rdns = "www.example.com"
address = "${linode_instance.www.ip_address}" // or call this address_ipv4
address_ipv6 = "${linode_instance.www.ipv6}"
}
I'm leaning towards the first or second approach.
This wouldn't be a direct 1-to-1 with the API, but I think it would be problematic to try to shoe horn an attribute like rdns
in to linode_instance
since:
RDNS support was added to LinodeGo in https://github.com/linode/linodego/pull/66
This can move forward.
Is there a timeline for when the Reverse DNS support will be shipped?
@hielee The short answer is that I don't have a timeline for this.
Feedback like this is a key motivator that there is interest in a feature. @rmcintosh happened to ask me if this was a feature of the Terraform provider today too.
This now holds a much more central position on my personal radar.
PRs always welcome. I think I can find time in the next 30 days to work on this. This thread will hold me accountable. 🤞
I was thinking about an alternate approach that aligns with the /v4/networking/ips
space, which includes RDNS, IPv4 sharing, IPv4 assignment, and address details (such as routing address).
This would be a linode_address
resource, and would combine the features of:
GET /networking/ips/{address}
(address details)POST /networking/ips
(assign additional IP to Linode)PUT /networking/ips/{address}
(set RDNS)POST /networking/ipv4/assign
(assign/move IP address)POST /networking/ipv4/share
(floating IP support, multiple Linodes can bring up a specific set of IP addresses (but in practice, only one instance at a time can use any particular address))It could look like this:
linode_address
address
optional/computed
linode_id
(sharing could be established using the linode_ids
field (should this prefixed? sharing_
?))rnds
optional/computed
public
optional/computed (bool) Public or Private, needed when creating a new address, but also returned/computed when getting the details of an existing addresstype
optional/computed 'ipv4' or 'ipv6', this is a required field when adding an IP address, but it is also computed when retrieving details of an addressThe other fields that would be provided would align with those provided by GET /networking/ips/{address}
Taking advantage of the API design and aligning these properties and functions with a related resource feels idiomatic for Terraform.
But, I don't know if this is a sound design for a Terraform resource. The data
resource aspect of this seems like a code smell. By data
resource aspect, I mean the ability to provide an existing address and have a resource that doesn't create something, but instead is populated with the values of something that already exists.
Another concern is that this resource would encompass nearly all IPv4 and some IPv6 API methods. Trying to shoehorn the remaining IPv6 features into this one resource is tempting, but I'm not convinced that they can be made to fit. Especially because these remaining endpoints deal with ranges/pools of IPv6 addresses.
@dave-lew99 would this approach suite your needs?
Swapping IP addresses may interfere with parallel provisioning steps and might require rebooting nodes to apply the desired changes. Floating IPs (IP Failover, IP Sharing) don't require a swap so it should be safe in a Terraform setting.
The IP donor node may need to be accessed/provisioned over IPv6.
I'm not too famlier with the Linode platform and it's particular behaviour, but yes that sounds like it would work for us.
On other platforms we create a floating IP allocation in terraform, then have create_before_destroy set on the instance - causing the new instance to be launched and have the IP assigned to the new instance before the old one is destroyed.
I suppose we could also use a load balancer - this would allow us to keep the same IP/DNS config and zero downtime, but it's additional cost and complexity.
Terraform Version
Terraform v0.11.9
Feature Request
References