GitLab

it's intended to be used as an interface between ClientList and
ZoneTableSegment.

in fact, we shouldn't have shared the same segment even before; the header
part should be created per data source.  So this is actually a bug fix.

so it can be shared by multiple tests.

The interface to get cache properties from the client list.

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

Also fix typos in afsdb_18.cc doxygen comments.

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).

Instead of hard-coded enum type. The data source should be agnostic to
the type.

Saying the segments are for in-memory cache. Also adding note about
future extending and exceptions.

SEGMENT_MAPPED may be misleading in case of locally-allocated memory.
Using SEGMENT_INUSE.

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").