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. Maybe that's easier than I think it its?
And we'd have to deal with people who are passing in the endpoint url to begin with (ex_force_base_url). Do we now allow them to pass in another endpoint for the rdns methods (ex_force_base_dns_url)? Or do we make them create a dns driver then pass that along to the compute objects? You can see that that gets awkward quickly, but I'm open to suggestions if there's an elegant way to handle it. Greg On 11/25/15, 5:08 AM, "Tomaz Muraus" <[email protected]> wrote: >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 >> > >>
