GitLab

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

So that output of addresses is now consistent