I'm really sorry about this.  It's my regression in 5.5.0 (!1225)

Practical consequence was that the RW transaction was held open
until that instance did something with cache (and thus closed),
so any other instance would be frozen in the meantime if doing
anything non-read-only with cache (e.g. startup).
https://lists.nic.cz/hyperkitty/list/knot-resolver-users@lists.nic.cz/thread/6DOXXOA6ACEUBVYPUY3T2MLGIHWOMV6M/

In a few places the tag-set specification for jobs could match
either amd64 or arm64 runners.  That non-determinism is bad,
especially when passing platform-specific artifacts around.

This is just a stop-gap measure.  Later we'll need to rethink our CI
in terms of the two platforms.

I didn't touch tag-sets with `condor`, as that will probably always be
just a single machine (which coordinates scheduling on others).

The apkg installation through pip3 was pulling too new jinja2 version,
breaking subsequent usage of sphinx to build docs (in `apkg build`).

Fixes #735

It's probably a bit more efficient, but this part of code should be
rarely used even on a resolver serving all in XDP.

Somehow I did this wrong when porting to libknot 3.1.

* set myself as package maintainer
* use {{ now }} instead of hardcoded datetime
  * bump apkg compat to 2

This is a no-op as GPG_CHECK is disabled for upstream package but it
keeps the .spec files in sync.

Fixes #727

Oto Šťáva authored 3 years ago and Vladimír Čunát committed 3 years ago

Also change the return type of kr_pkt_has_dnssec() and lua's :dobit()

release 5.5.0

See merge request !1272

We're still run into people who thought that the example config
is a suitable default.  Example where it caused practical issues:
https://lists.nic.cz/hyperkitty/list/knot-resolver-users@lists.nic.cz/thread/WQDJJ3LLEIZ5U3VVSCITW6DZPICW4L7U/

lib/selection: fix interaction of timeouts with reboots

Closes #722

See merge request !1269

This reverts commit 0c9ea133 (!1226).

CI rp:fwd-tls6.udp-asan now repeatedly shows use-after-free.
That could be a serious issue, and this commit's feature
seems less important than the risk.  Let's revert until the issue
gets deeper investigation.

We use "monotonic" time-stamps for the dead_since field;
that breaks on system reboots, in which case we reset the stats.
(if the server was categorized as dead)

If the server times out afterwards, we'd fail the condition
`cur_state.consecutive_timeouts == old_state.consecutive_timeouts`
so its stats would not update.  Therefore we'd get stuck forever
in a state where the unusable server has high priority (no_rtt_info).

This commit changes a bit more than was necessary to fix this,
including precision of the stats (in some cases).

The approach was dubious: random shuffle, qsort() and choose the first.
The main functional problem was that qsort() isn't a stable sort,
so the effect of pre-shuffling is not reliable, even though I don't have
any evidence of this causing issues in practice.

The new code should also be a bit more efficient in terms of CPU and
consumed randomness, but that probably won't be noticeable.
The arrays passed into select_transport() are now const (no sorting),
which could make the code easier to "understand".

ci: remove experimental arm builds

See merge request !1270

These are running on a hardware setup which is hard to maintain. In the
near future, ARM64 should be covered by a dedicated runner.

pgp: remove tkrizek, add amrazek

See merge request !1268

distro/tests: use rocky8 instead of centos8

See merge request !1267