Cleanup before introduction of new packaging tests.

See: #612

fix kresctl packaging

See merge request !1344

This reverts commit 16ea2c8f.

- downgraded pinned version of supervisord
- installing procps in CI

release 5.5.3

See merge request !1343

It's a mitigation for CVE-2022-40188 and similar DoS attempts.
It's using really trivial approaches, at least for now.

manager: fully featured HTTP API

See merge request !1331

This fixes config_tests on aarch64 macOS.
The key difference is that they use 16k pages,
so LMDB space usage also behaves a bit different.

Vaclav Sraier authored 2 years ago and Aleš Mrázek committed 2 years ago

manager dependencies: accept just about any pyyaml (problems with kresctl refusing to launch due to version mismatch)

Vaclav Sraier authored 2 years ago and Aleš Mrázek committed 2 years ago

- adds versions to URL's (closes #759)
- adds a basic packaging test for consistent etags
- adds a basic packaging test for working metrics
- fix bugs with API implementation
- fix bugs with /metrics endpoint

doc: sphinx-tabs added

See merge request !1335

- added reference to usecases chapter

That option isn't supported there, so the test wouldn't work.
Now the config tests work for me on x86 macOS.

Enums are more like ints anyway (in standard),
even when drawn from a small subset.

So far the message wasn't pointing to freebind at all:
[net   ] bind to '::1@53' (UDP): Operation not supported

I used preprocessor to avoid duplication and unused warnings.

Another way would be to ignore the freebind option if not supported,
but I think it's better to convince users not to specify it.

release 5.5.2

See merge request !1337

21.10 isn't supported anymore, which is probably why it's failing.

We've already done that on OBS side, which is probably why it's failing.

https://github.com/lunarmodules/luacov/issues/99

We're mostly using those in NEWS and first line of commit messages.
I'm not sure if they're much better than alternatives, but at least
consistency is nice.

This caused a huge increase in real memory usage in case of queries
arriving to kresd while being disconnected from internet.
The usage was slowly creeping up, even over 2G.

Interesting past commits: b350d38d and two preceding.

There apparently was no real memory leak.  I assume that reusal of
long-living mempools is risky in terms of memory fragmentation,
though the extent of the issue surprised me very much.
The issue seemed the same with normal glibc and jemalloc.

I generally dislike ad-hoc optimization attempts like these freelists.
Now the allocator can better decide *itself* how to reuse memory.