GitLab

without this we can't catch the case where zonemgr isn't running timely.
a unit test is updated to check that condition, too.

also made some methods const member functions as they don't have to be
mutable.

so others won't waste their time by trying to use it...
same note applies to groupRecvMsg, so added the same note.

the behavior itself is the same, but it suppresses noise level in case
it's intentional configuration.  descriptions of other log messages in
this method were not really correct, so they were fixed, too.

also, it now asserts xfrin_session_ is non null; this should never be null
in the production code (even tests don't set it to null right now).

resetting "xfrin session" to NULL doesn't make much sense because it shouldn't
happen in production case, so I simply updated the existing test case
(and renamed it) rather than adding a new one.

In the end we'll need to address the threading model in zonemgr, but this should be a good short-term workaround for the problem.

Using of constants from proto_defs instead of hard-coded magic keywords.

and add test for it

It has been failing on distclean for around a week at least
due to file left around.

Newer python's keep under __pycache__ which was already handled.

Reviewed on jabber.

This is ticket http://bind10.isc.org/ticket/2747

It has been failing on distclean for long time
due to file left around.

Newer python's keep under __pycache__ which was already handled.

Reviewed on jabber.

msgq_run_test.py uses src/lib/python/isc/cc/proto_defs.py which
uses cc_generated version which created some .pyo files:
./src/lib/python/isc/cc/cc_generated/__init__.pyo
./src/lib/python/isc/cc/cc_generated/proto_defs.pyo
which are left over after distclean.

quick review via jabber

to support prefix delegation which has not been designed yet.

Few more occurrences of the magic keywords scattered through the code
replaced by constants.

(it didn't make sense before this branch, but now it could cause regression
as we remove the 'new' qualifier).

in some cases we can't simply use 'new' (but normally safe without it),
and in some cases we need additional synchronization points to make it
work more reliably.

previously the semantics was a bit ambiguous and resulted in some
less predictable behavior. (and, non suprisingly, some usage cases
in features seem to be wrong about "wait for new").

So that output of addresses is now consistent

mainly for rationalizing lettuce tests that are coming after this.

it's now a debug message, and the description is revised to explain the
situation more correctly.

it can happen if the server is a primary of the zone; notauth case is
now handled in auth.

also improved in-auth and not-auth cases of logs with the sender endpoint
information.