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 <[email protected]> wrote: > 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 > >> > > >> > >
