Then let's just go for it (insert here ref. to upcoming separate task :-)).

In T3887#77951, @zack wrote:

Do you foresee any issue in adding extra_headers to releases as well, other than "someone should do it"?

In T3887#77949, @olasd wrote:

Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.

Now that I've written it out loud, of course, Releases don't have extra_headers so the package loaders can't make use of this workaround/hack for now.

From merged tasks, this would also be useful for some package loaders, e.g. npm, that support multiple authors in their packaging metadata.

Practically, we could be storing the metadata on additional authors *now* in the extra_headers field (make them a bunch of (b'author', b'XXX <yyy@zzz.ttt>') entries). Of course, that doesn't solve the question of presenting the information.

Is this information fully intrinsic, or can it be modified without the revision id changing ?

Diff fixed it ^

Rebase

Rebase

LGTM, it's not really ideal but it avoid to break the current subnet spliting we are using

Update

Build is green

Fix docstring

Build is green

Remove dead code

What's currently missing [1] in the state of the diff is the icinga check on the sentry service (moved to rp1).
With the proper means to define the http_uri value.

yeah!

See T3893 instead.

From IRC:

Add misses changes

Use correct range of commits

we can always improve it, but now we have a decent dashboard, so let's consider this done.

Seems moslty ok, even if these errors still pop now and then in the logs.

That works for me

Adapt according to review

Unfornunately I didn't find any tool supporting natively the backup of postgresql through zfs snapshots.
We have a couple of alternatives:

• Use borg to to implement a clean backup of the postgresql data directory based on hooks [1]
• Use a tool like pgbackrest[2], the backup type and storage target need to be choosen (S3, storage server, ...)
• Implement a backup based on zfs snapshots, which should not be too complicated but we need to manage all the plumbing to deal with full/incremental backups and the history cleaning

Arcanist is bugged with the new PHP 8.1, so I'll wait until I have addressed everything to try to re-send, in the mean time, some questions

Should we have an ad-hoc coding of sorts?

related to T3889

It seems like the expected type of Tuple[Tuple[bytes, bytes], ...] does not offer any nesting opportunities. Should we have an ad-hoc coding of sorts? Am I just missing something?

In D6344#182786, @Alphare wrote:

I will have to retrace my steps, but yes, it's probably a good idea. Would a shell script work?

extra_headers looks like the best way to do this.