Open Stack

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)