Open Stack

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 at 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)
>