Page MenuHomePhabricator

openstack: work out IPv6 and designate integration
Closed, ResolvedPublic

Description

We want the FQDN for VMs to have an IPv6 record registered in openstack designate.

This ticket is to track the work to make it happen.

Event Timeline

aborrero triaged this task as Medium priority.Sep 18 2024, 2:07 PM

Guys I would propose the following for the reverse/PTR records:

  • We delegate the allocated 'public' and 'private' ranges to the codfw openstack NS servers in the zone for 2a02:ec80::/29
    • This effectively makes those two allocations just for use/management by OpenStack/Neutron
    • We can allocate other ranges for use on networks not managed by OpenStack as needed
    • Currently we only have one of these assigned, 2a02:ec80:a100:fe00::/55 - where we will assign IPs for use on cloudsw, cloudgw etc for routing
    • That network, and any other similar, we will continue to use Netbox to manage IP assignment and DNS names.

Change #1076713 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/dns@master] Delegate IPv6 ranges allocated for WMCS Openstack networks in codfw

https://gerrit.wikimedia.org/r/1076713

Change #1076713 merged by Cathal Mooney:

[operations/dns@master] Delegate IPv6 ranges allocated for WMCS Openstack networks in codfw

https://gerrit.wikimedia.org/r/1076713

Change #1079312 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/dns@master] Fix WMCS openstack reverse delegations in codfw

https://gerrit.wikimedia.org/r/1079312

Change #1079312 merged by Cathal Mooney:

[operations/dns@master] Fix WMCS openstack reverse delegations in codfw

https://gerrit.wikimedia.org/r/1079312

Reverse delegation is now working for the ranges we've assigned to OpenStack. I've not gotten an answer for the one IP I can see is on the network (2a02:ec80:a100:1::1/64 on cloudnet2006-dev), but that may be expected, and I'm not sure if there are any actual instances running now or their addresses.

cathal@officepc:~$ dig -x 2a02:ec80:a100:1::1 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -x 2a02:ec80:a100:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43495
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1400
; COOKIE: b3cc741eb68f1fd10100000067080a006d51e30fe7794840 (good)
;; QUESTION SECTION:
;1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.1.a.0.8.c.e.2.0.a.2.ip6.arpa. IN PTR

;; AUTHORITY SECTION:
1.0.0.0.0.0.1.a.0.8.c.e.2.0.a.2.ip6.arpa. 3155 IN SOA ns0.openstack.codfw1dev.wikimediacloud.org. root.wmcloud.org. 1728042768 3563 600 86400 3600

;; Query time: 0 msec
;; SERVER: 192.168.240.1#53(192.168.240.1) (UDP)
;; WHEN: Thu Oct 10 18:08:16 IST 2024
;; MSG SIZE  rcvd: 220

But everything upstream is working ok at least.

aborrero changed the task status from Open to In Progress.Oct 21 2024, 12:43 PM
aborrero moved this task from Backlog to Doing on the User-aborrero board.

Let me check what is left to be done here.

aborrero changed the task status from In Progress to Stalled.Oct 23 2024, 12:32 PM
aborrero moved this task from Doing to Blocked/waiting on the User-aborrero board.

Turns out, to enable PTR creation support, per T377740: neutron: clarify why DNS extension is not enabled we would need to either:

  • extend our custom code to support this new IPv6 settings
  • switch to neutron DNS integration upstream code, which seems to support IPv6 natively

I'll mark this ticket as blocked until one of the two options have been implemented.