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/#add-ptr- records It requires both an 'href' and a 'rel'. Right now, for the Rackspace Node objects, you can get the 'href' from node.extra['uri'], but the 'rel' field would have to be ferreted out from the service catalog somehow. https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/open stack.py#L2117 Note: link['rel'] in that context is not the same as the 'rel' that the RDNS API requires. The loadbalancer driver does not provide either bit of needed metadata: https://github.com/apache/libcloud/blob/trunk/libcloud/loadbalancer/drivers /rackspace.py#L1382 Should I update both drivers to add the relevant metadata first? I think it should be achievable, but I am not as familiar with the service catalog code that I'll need to get at to figure out what the 'rel' is. Greg On 11/26/15, 11:24 PM, "anthony shaw" <[email protected]> wrote: >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 >> >> > >> >> >> >>
