[designate] About delegating PTR using shared zones on a shared internal network
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)
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)
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)
Yes, I have fixed and backported the bug I mentioned at the summit. Here is the list of patches: https://review.opendev.org/c/openstack/designate/+/887425 https://review.opendev.org/c/openstack/designate/+/884554 https://review.opendev.org/c/openstack/designate/+/884347 https://review.opendev.org/c/openstack/designate/+/880691 https://review.opendev.org/c/openstack/designate/+/879208 https://review.opendev.org/c/openstack/designate/+/726334 Michael On Fri, Jul 14, 2023 at 2:31 AM Thomas Goirand <zigo@debian.org> wrote:
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)
participants (2)
-
Michael Johnson
-
Thomas Goirand