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 <[email protected]> wrote: > 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 Wed, Nov 25, 2015 at 3:43 AM, Greg Hill <[email protected]> > wrote: > > > 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 Rackspace). > > > > My current plan is to add these methods to the rackspace dns driver: > > > > ex_create_ptr_record > > ex_delete_ptr_record > > ex_iterate_ptr_records > > ex_get_ptr_record > > _ex_to_ptr_record > > > > And the returned type will be a subclass of dns.types.Record called > > RackspacePTRRecord. The primary difference is that PTR records belong > to a > > zone that the customer doesn't own, so the Record.zone accessor makes no > > sense. I plan to make it throw an exception informing the user as such. > > Alternatively I could make a fake zone record with the relevant rdns zone > > name (x.x.x.in-addr.arpa), but no id, but I didn't think that was worth > the > > bother since it might make a user think they can just treat it like other > > zones and pass it to create_record, etc. > > > > Since one of the things with RDNS is that they need to validate a) that > > they serve RDNS for the IP in question and that b) you as a customer > > actually own that IP, I have to imagine every implementation is unique. > > Rackspace requires you to pass in an 'href' to the cloud server or cloud > > loadbalancer, and they then do a lookup on the backend to verify that a) > > your tenant owns that resource and b) the IP in question belongs to it. > At > > LiquidWeb (my previous employer), we did that automatically so you didn't > > have to pass anything extra in, but it was still a unique API endpoint > > because it was a zone the customer didn't control. > > > > Another related fix is that the current DNS implementation lets you > > attempt to create a PTR record in your regular DNS zone, which just > fails. > > I was planning to alter the regular DNS provider to throw an exception if > > you attempt to add a PTR record so it fails before submitting it to the > API > > and saves you some trouble. Should I extend this to other DNS providers > as > > well? I seriously doubt any of them let you attempt to add a PTR record > to > > a regular zone because that's not how RDNS works. > > > > I appreciate any input. I don't have the cycles right now to attempt to > > do this for all of the supported providers, but if someone does and wants > > to help out, I'd accept the help. Otherwise, maybe we can use this as an > > mvp and add other driver support over time. > > > > Greg > > >
