Hi Thomas, Thanks for the kind words. Using a sink work certainly work. This is kind of the "next step", to understand how people do IPAM and what is the right way to automate this. Ideally you would allocate blocks of IPs to a project, but I realize many deployments are not set up that way. The other thing to think about is if you use one of the neutron extensions that create records based on the network domain and port dns name. You could get into an interesting situation where the configuration in neutron no longer matches the PTR records if you allow users to "own" their PTR records in Designte. Michael On Thu, Jul 6, 2023 at 2:26 AM Thomas Goirand <zigo@debian.org> wrote:
Hi there!
I have just watched Michael Johnson's video of the presentation at the last Vancouver summit: https://www.youtube.com/watch?v=zdhvNezU1w4
This was very interesting, and thanks Michael, for that awesome feature.
In our use case, we created an OpenStack internal network, that is shared for all of our customers, so that they can allocate public IPs assigned directly to their instances, without the need to create a router and use NAT.
For the moment (since we don't have the shared zones feature yet), we manage the PTR record through support tickets. We'd like to move forward, and delegate the PTR handling to our customer, whenever they allocate a port on that specific shared network. How can this be done?
Should we create a new sink of our own, so that we would automate the the shared zone creation, so that it would delegate the in-addr.arpa. range, when a port on that network is created, and the same way, remove the delegation (and records) whenever the port is deleted? Would this be something similar, probably, we the sink we implemented to automatically delete PTR records in floating IPs, available here [1]?
[1] https://salsa.debian.org/openstack-team/services/designate/-/blob/debian/ant...
I'd love to have some pointers / examples, so we could implement this directly in Designate, so that the feature could be shared in the OpenStack community. For sure, we aren't the only public cloud provider with the use case...
Cheers,
Thomas Goirand (zigo)