Both designate and designate-bind charms are ignoring dns-backend binding

Bug #1722794 reported by Tytus Kurek
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Designate Charm
Fix Released
Critical
Tytus Kurek
OpenStack Designate-Bind Charm
Fix Released
Undecided
Tytus Kurek
charms.openstack
Invalid
Critical
Tytus Kurek

Bug Description

Designate (cs:~openstack-charmers-next/designate-51) and designate-bind (cs:designate-bind-9) charms have been deployed using the following commands:

juju deploy --series trusty --num-units 3 --bind "provisioning admin=openstack-admin internal=openstack-internal public=openstack-public dns-backend=openstack-internal" --config /home/tytus/designate.yaml --to "lxd:0,lxd:1,lxd:2" /home/tytus/charms/designate designate

juju deploy --series trusty --num-units 3 --bind "provisioning dns-backend=openstack-internal" --config /home/tytus/designate-bind.yaml --to "lxd:0,lxd:1,lxd:2" /home/tytus/charms/designate-bind designate-bind

tytus@maas:~$ cat designate.yaml
designate:
  debug: "true"
  enable-host-header: "true"
  openstack-origin: "cloud:trusty-mitaka"
  region: "Softlayer"
  use-syslog: "true"
  verbose: "true"
  vip: "10.24.111.14 10.24.112.14 10.24.113.14"

tytus@maas:~$ cat designate-bind.yaml
designate-bind:
  debug: "true"
  use-syslog: "true"
  verbose: "true"

in juju environment with the following spaces:

tytus@maas:~$ juju list-spaces
Space Subnets
openstack-admin 10.24.111.0/24
openstack-internal 10.24.112.0/24
openstack-public 10.24.113.0/24
provisioning 10.24.110.0/24

This results with the following files being created:

- on designate side:

root@juju-058026-0-lxd-31:~# cat /etc/designate/pools.yaml
- id: 794ccc2c-d751-44fe-b57f-8894c9f5c842
  name: default
  description: Pool genergated by Juju

  nameservers:

    - host: 10.24.110.251
      port: 53

    - host: 10.24.110.203
      port: 53

    - host: 10.24.110.250
      port: 53

  targets:

    - type: bind9
      masters:

        - host: 10.24.110.172
          port: 5354

        - host: 10.24.110.180
          port: 5354

        - host: 10.24.110.233
          port: 5354

      options:
        rndc_host: 10.24.110.251
        rndc_key_file: /etc/designate/rndc.key

    - type: bind9
      masters:

        - host: 10.24.110.172
          port: 5354

        - host: 10.24.110.180
          port: 5354

        - host: 10.24.110.233
          port: 5354

      options:
        rndc_host: 10.24.110.203
        rndc_key_file: /etc/designate/rndc.key

    - type: bind9
      masters:

        - host: 10.24.110.172
          port: 5354

        - host: 10.24.110.180
          port: 5354

        - host: 10.24.110.233
          port: 5354

      options:
        rndc_host: 10.24.110.250
        rndc_key_file: /etc/designate/rndc.key

  also_notifies:

    - host: 10.24.110.251
      port: 53

    - host: 10.24.110.203
      port: 53

    - host: 10.24.110.250
      port: 53

- on designate-bind side:

root@juju-058026-0-lxd-32:~# cat /etc/bind/named.conf
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

controls {
  inet 10.24.110.251 allow { 10.24.110.233;10.24.110.180;10.24.110.172; };
};

root@juju-058026-0-lxd-32:~# cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk. See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys. See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;

        auth-nxdomain no; # conform to RFC1035
        listen-on-v6 { any; };
        allow-new-zones yes;
        request-ixfr no;
        recursion no;
        allow-notify { 10.24.110.233;10.24.110.180;10.24.110.172; };
};

As you can see all IPs belong to the 10.24.110.0/24 subnet ("provisioning" space), so the communication between designate and designate-bind uses this space instead of "openstack-internal", although it has been specified when deploying the applications.

Tytus Kurek (tkurek)
tags: added: 4010 cpe-onsite
Tytus Kurek (tkurek)
Changed in charm-designate:
assignee: nobody → Tytus Kurek (tkurek)
Changed in charm-designate-bind:
assignee: nobody → Tytus Kurek (tkurek)
Changed in charm-designate:
status: New → In Progress
Changed in charm-designate-bind:
status: New → In Progress
Revision history for this message
David Ames (thedac) wrote :

We recently fixed issues with the "external" bindings admin, internal and public. This DTRT for conical_url and resolve_address for use when publishing to the keystone catalog.

However, we are not handling arbitrary relations in reactive charms. charms.openstack needs something similar to or to use get_relation_ip in charmhelpers:
https://github.com/juju/charm-helpers/blob/master/charmhelpers/contrib/network/ip.py#L559

We need to support network_get calls with arbitrary relationship interface names, in this case, dns-backend.

Changed in charm-designate:
status: In Progress → Confirmed
importance: Undecided → Critical
milestone: none → 17.11
Changed in charms.openstack:
status: New → Confirmed
importance: Undecided → Critical
Tytus Kurek (tkurek)
Changed in charm-designate:
status: Confirmed → In Progress
Revision history for this message
Tytus Kurek (tkurek) wrote :

I have a working patch. I'll upload it for a review once unit tests are ready.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-designate-bind (master)

Fix proposed to branch: master
Review: https://review.openstack.org/511505

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-designate (master)

Fix proposed to branch: master
Review: https://review.openstack.org/511507

Revision history for this message
Tytus Kurek (tkurek) wrote :

I've created a new pull request against "charm-interface-bind-rndc" project:

https://github.com/openstack/charm-interface-bind-rndc/pull/1

and submitted charms for a review:

https://review.openstack.org/511505
https://review.openstack.org/511507

Revision history for this message
Tytus Kurek (tkurek) wrote :

I didn't realize there's gerrit project for charm-interface-bind-rndc:

https://review.openstack.org/511547
https://review.openstack.org/511505
https://review.openstack.org/511507

Tytus Kurek (tkurek)
Changed in charms.openstack:
assignee: nobody → Tytus Kurek (tkurek)
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-designate-bind (master)

Reviewed: https://review.openstack.org/511505
Committed: https://git.openstack.org/cgit/openstack/charm-designate-bind/commit/?id=f514bb5a17690d95266d4b275a5ddc2cd1b3059e
Submitter: Zuul
Branch: master

commit f514bb5a17690d95266d4b275a5ddc2cd1b3059e
Author: Tytus Kurek <email address hidden>
Date: Thu Oct 12 17:26:07 2017 +0200

    Implement "dns-backend" binding

    This patchset implements "dns-backend" binding which is required to
    properly handle DNS zone transfers between designate and
    desigante-bind applications. If "dns-backend" binding is provided
    when deploying designate and designate-bind applications, DNZ zone
    transfers will now take place over the subnet which belongs to the
    provided space.

    Change-Id: Icbe0cc790c565f125f0fe8c903e9b755fe764d7c
    Depends-On: I927e3958cf929ace9d43f8b3d9509b90b9eab60f
    Partial-Bug: #1722794

James Page (james-page)
Changed in charm-designate-bind:
status: In Progress → Fix Committed
Tytus Kurek (tkurek)
Changed in charms.openstack:
status: In Progress → Invalid
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on charms.openstack (master)

Change abandoned by James Page (<email address hidden>) on branch: master
Review: https://review.openstack.org/511881
Reason: This change is no longer required (will be implemented directly into designate charm).

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-designate (master)

Reviewed: https://review.openstack.org/511507
Committed: https://git.openstack.org/cgit/openstack/charm-designate/commit/?id=9bc1b2c05b34c490803145afbc25478cdf6c0692
Submitter: Zuul
Branch: master

commit 9bc1b2c05b34c490803145afbc25478cdf6c0692
Author: Tytus Kurek <email address hidden>
Date: Mon Nov 13 11:30:12 2017 +0100

    Implement "dns-backend" binding

    This patchset implements support for "dns-backend" binding. Use the
    "dns-backend" relation network space binding to populate the list
    of dns master servers in the designate pool configuration,
    ensuring that communication between master and slave servers
    happens over the correct network space.

    Depends-On: I927e3958cf929ace9d43f8b3d9509b90b9eab60f
    Depends-On: Icbe0cc790c565f125f0fe8c903e9b755fe764d7c
    Change-Id: I2c7b95e630611ac16c19e7f9efb81f54802849e9
    Closes-Bug: #1722794

Changed in charm-designate:
status: In Progress → Fix Committed
James Page (james-page)
Changed in charm-designate-bind:
milestone: none → 17.11
James Page (james-page)
Changed in charm-designate:
status: Fix Committed → Fix Released
Changed in charm-designate-bind:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.