On 7/10/23 23:03, Michael Johnson wrote:
Ideally you would allocate blocks of IPs to a project, but I realize many deployments are not set up that way.
You are right, that's not the way it works in our deployment. As we implemented a public cloud, and have thousands of customers, it's not doable to manually assign a block of IPs to a customer with an admin command. What we have is a network that we called "ext-net1". It is an internal OpenStack network (with a router and its default gateway owned by the admin user), on which we added multiple /24 subnet blocks of public IPs. Typically, a user would create a port on this "ext-net1" and use it when doing "openstack server create" to optain a (random) public IP on that network. Or, using "openstack server create --nic net-id=ext-net1". In this scenario, what we want is automatically assigning the PTR subzone matching the individual IP address to be: 1/ created (as admin) 2/ shared with the customers project (openstack zone share create), so the customer can add a PTR record 3/ if possible, also automatically create a PTR record on the behalf of the customer, so there's a default value in place. When the port is deleted, we would like the subzone to be deleted automatically as well.
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.
We are using scenario 3a, so customers can do whatever they want with the IP address they own.
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.
Well, if the port name and domain doesn't match the PTR record, it may look ugly, but I don't think that's a real problem. I couldn't care less, if at least it's doing what we expect (ie: let our customers create forward and reverse entries, in a way that can be shared with other customers without any conflict). As we're still in Victoria (currently planning the upgrade to Zed), we wont be able to contribute what I described above in a foreseeable future. The situation *may* change at the end of this year though, if we successfully upgrade to Zed, and if I can backport the shared zone patches. BTW, it would be great if, like we discuss in the summit, you could send me a list of patch, in the correct order, so I could backport the shared zones feature to Zed. Of course only do that if it doesn't take too much of your time... Also, did you backport the bugfix you told me was missing to Antelope? Thanks for all of your work, Cheers, Thomas Goirand (zigo)