In theory, I agree. There's one hiccup. The RDNS API works for servers
*and* loadbalancers, but the Node and Loadbalancer objects in libcloud do
not provide the necessary metadata that the RDNS API needs in a consistent
manner.
https://developer.rackspace.com/docs/cloud-dns/v1/developer-guide/#
good point, maybe create a method in the dns driver that accepts a node. in
the same way in the load balancer driver there's an attach_node method.
that way you can access the IPs and it's easier for the user to understand
what they're supposed to pass.
On Wed, Nov 25, 2015 at 11:47 PM, Greg Hill
It's an interesting idea, and I agree that it would make sense from an
end-user perspective, but I'm not sure it'll work in this case. It's a
different API endpoint from the compute driver. We'd have to hack into
all the service catalog stuff to pull a different endpoint for just the
rdns methods
Yeah, I believe that's also what I suggested in the past ( adding it to the
compute driver).
As far as your proposed DNS driver extension methods go - I'm also fine
with that for the Rackspace DNS driver.
On Tue, Nov 24, 2015 at 11:46 PM, anthony shaw
wrote:
> Hi Greg,
>
> I know PTRs are stric
Hi Greg,
I know PTRs are strictly 'DNS' but this seems like it belongs in the
compute driver instead of the DNS driver. the implementation is going to be
a bit wonky otherwise.
That way you could just set PTR record for a node. Then it can lookup the
public_ips from the existing field.
Ant
On We
I'm working on adding PTR support to the Rackspace DNS driver as an extension.
It's my understanding that not all providers offer an API for RDNS, so I didn't
think it was worth adding to the base dns driver. Because you don't own the
zone, the API endpoint is different (/rdns in the case of R
