lazypower / dns-charm Goto Github PK

Tox is a pretty good framework to manage venvs and other project structures. Lets nuke the custom schenanigans in the Makefile and leverage tox.

The output of the hostname check + resulting dig +short command returns an inconsistent hostname on MAAS based hosts.

In [4]: subprocess.check_output(['dig', '+short', hostname.strip()]).strip()
Out[4]: '10-0-10-55.maas.\n10.0.10.55'

This will result in an unparse-able config by the named-checkzone utility, plus can cause unintended side effects in domain resolution by any host outside of the provider environment.

The testing structure needs some love in this charm.

Contrib/tests seems off to me, and they should probably live under unit_tests along with other unit_tests for the charm, and the 'tests' dir should contain functional tsts. or subdivide out the 'tests' directory with runners for both test styles.

Either way, whats here is a mess and its difficult to get going again.

The relation data is no longer a BIND style newline separated document.

The current format of relation data is a JSON object, or array of JSON objects for each record type depending on programmable or programmable-multiple

 {'alias': 'test', 'ttl': 1600, 'rr': 'A', 'addr': '127.0.0.1'}

Charm helpers lives in pypi, and they should be pulled from pypi to simplify code + updates.

the programmable relation returns with no feedback to the user if no domain is passed on the wire, and this break user e xpectations.

If you set a new line, the newline is transferred to the resulting dict, causing an issue with AWS Rt53. The values should be trimmed during the parsing.

Forwarding should be a configurable option for BIND deployments. If the nameserver is listed first in resolv.conf it will fail to push not-found entries to a remote service, since we occupy the first slot in most resolv.conf configurations - it makes sense to attempt to forward requests to the existing nameserver on the machine.

The new testing format is using TOX. Charm-helpers is now pip installable, and various other cleanup needs to happen to assist new contributors.

Given the example of offline.myhacks.net as the domain to work with, subsequent subdomains should be appended such as

ns1.offline.myhacks.net

In the charms current existance it will reparse the zone and treat myhacks.net as the domain, and generate invalid configuration for CNAMES such as ns1.offline.

AWS Rt53 has a fully programmable API, and even if a basic single domain integration, this would be a good jumping off point to start integrating with third party providers.

I'm using the DNS charm's programmable-multiple interface as part of the Clearwater Juju Charms (at https://github.com/Metaswitch/clearwater-juju/tree/dnsaas).

When nodes add a relation to the DNS charm, DNS records are created. However, on departure, they aren't deleted.

This causes an issue for elastic scale-up/scale-down as, after scale-down (and units departing the relation), their records are still present in DNS, so we try to load-balance across a large set of dead nodes.

It looks as though the programmable-multiple-relation-departed hook isn't implemented. Are there any plans to add this?

I recently rebuild my Juju OpenStack rig, which meant I had to re-download my Ubuntu images. I pulled down Ubuntu 12.04.5, where previously I was using Ubuntu 12.04.4. (I'm not sure if this is relevant, but it seems to be the only change I can see.)

When I deploy the DNS charm (whether I do it in online or offline mode), I get the following error:

unit-dns-0[3910]: 2016-08-01 19:33:02 INFO unit.dns/0.install logger.go:40 Traceback (most recent call last):
unit-dns-0[3910]: 2016-08-01 19:33:02 INFO unit.dns/0.install logger.go:40   File "/var/lib/juju/agents/unit-dns-0/charm/hooks/install", line 75, in <module>
unit-dns-0[3910]: 2016-08-01 19:33:02 INFO unit.dns/0.install logger.go:40     i.install_provider()
unit-dns-0[3910]: 2016-08-01 19:33:02 INFO unit.dns/0.install logger.go:40   File "/var/lib/juju/agents/unit-dns-0/charm/hooks/install", line 56, in install_provider
unit-dns-0[3910]: 2016-08-01 19:33:02 INFO unit.dns/0.install logger.go:40     import DNS
unit-dns-0[3910]: 2016-08-01 19:33:02 INFO unit.dns/0.install logger.go:40 ImportError: No module named DNS
unit-dns-0[3910]: 2016-08-01 19:33:02 ERROR juju.worker.uniter.operation runhook.go:107 hook "install" failed: exit status 1

It seems the DNS module isn't installed. I can fix this by juju ssh-ing into the machine and running sudo apt-get install python-dns*, followed by juju resolved --retry dns/0.

Should python-dns* (or maybe just one of python-dns or python-dnspython) be added to the apt_install line in hooks/install, or is this dependency supposed to be satisfied by the list in charm/requirements.txt?

As I say, I've worked around this, but it would be useful to understand how the dependency should be satisfied (and how it's been satisfied in the past, as it's clearly worked previously). Any pointers you can provide would be appreciated!

The ressource Json format needs to be documented to be able to write the other side of the hook ...

When relating to Clearwate all hooks failed, programmable (non multi) scripts runs BUT not entries are put in db.zone file when using bind..

test

In the current model, it is always assumed the DNS charm is providing the DNS. as of the crumbs of the rt53 branch are landing, this is not always the case, and we need a further qualifier to denote when the remote unit should add the host as a DNS server.

Over the programmable-multiple relation, I sent the following:

sprout-0 300 IN A 10.209.158.44

In /etc/bind/db.*, I see:

sprout-0        IN     A        10.209.158.44

The TTL has been dropped.