[Wishlist] Configurable Service IPs for bind servers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Designate-Bind Charm |
Fix Committed
|
Wishlist
|
Martin Kalcok |
Bug Description
Given an environment where openstack's designate is configured in a corporate DNS structure (or even registrar NS data) as the conditional forwarder for a given domain/set of domains, the upstream DNS or registrar entries must have static IPs to point to for the canonical reference for those zones.
Example:
zone example.org.
ns1.example.org A 10.0.0.10
ns2.example.org A 10.0.0.11
Given the typical situation of having two designate-bind9 units running, and running bind in a container or VM in the juju environment, the addresses assigned to the units' dns-frontend space binding will not necessarily stay the same (you can't preselect LXD IPs in MAAS deploys, and likely can't preselect IPs in VM deploys in clouds). When we need to recover or rebuild the designate-bind servers/service units, we will get new IPs that then would have to be populated back into upstream DNS or registrars.
I'd suggest that we add a "service_ips" config option to designate-bind charm to configure as IPs for the designate-bind units. To illustrate the possible solution:
Spaces:
internal: 192.168.0.0/24
external: 10.0.0.0/24 (dhcp range 10.0.0.
designate-bind:
bindings:
"": internal
dns_backend: internal
dns_frontend: external
options:
num_units: 2
service_ips: 10.0.0.10 10.0.0.11
Deploy the two units, they get 10.0.0.20 and 10.0.0.21. The first unit inteh cluster would then take the 10.0.0.10 IP address of the service_ips stack and mark it used in the cluster relation data, then the second unit would use the 10.0.0.11 address and mark it used in the cluster relation data. The units would then configure the IPs as additional addresses on the interface where the dns_frontend ip space is bound, and then advertises and configures any front-end relations and listeners to listen on the service_ips instead of the ips auto-assigned by the binding to dns_frontend.
This would allow us to recover designate-bind services without having to update upstream forwarding rules or registrar data which both run much more slowly with updates than juju/cloud iterations, depending on SOA, record timeouts, etc.
Changed in charm-designate-bind: | |
status: | New → Triaged |
Changed in charm-designate-bind: | |
assignee: | nobody → Martin Kalcok (martin-kalcok) |
status: | Triaged → In Progress |
FYI, this is semi-related to lp#1773377 where we're looking to pass dns_frontend IPs to n-ovs and n-gw charms via relation. Instead of this, we can workaround by using/configuring these vips/service_ips and just manually configure the IPs in all three charms plus squash an upstream no-relation- available issu with this feature.