Custom / Templated Filenames

[tjungblu]

(follow-up to the conversations that triggered #44)

We talked with the customer today and it turned out that they have a multi-tenant system where each tenant is separated by namespaces. They would like to have a way to distinguish the core-dumps by namespaces, so they can later on send them to the right tenant.

I can see the namespace is in the pod-info.json already, what do you think about making the filename configurable with an "sprintf"-style pattern? It's already pretty close if I look into it: https://github.com/IBM/core-dump-handler/blob/main/core-dump-composer/src/main.rs#L190-L193

Of course just adding the namespace to the existing format is easiest.

We continue with talks with their customers as well (it's a vendor/partner scenario) so take this with a grain of salt - will update accordingly as a comment.

[No9]

This has been discussed previously #28 (comment)
Changing the name of the external file shouldn't be too difficult but if they are in a multi-tenancy environment it might be better to do some post processing so they can enable access based on their use case.
Also note there may also need to scrub the corefile for personally identifiable information.

[tjungblu]

IIRC the ask was to do "coredump routing". So a tenant A will be notified of a new coredump once a pod crashed and a coredump was generated in a given namespace.

I believe there was no permission issue here - we already raised the PII concerns but the customer was sure that this is not a problem here. A system we pitched to them was to leverage an S3 upload and an SQS notification that would unpack the zip and route to the right place given the namespace in the json.

I will keep you posted here as the discussion goes along, in case we need to upload to a custom EMS (as in #48) we can directly build this into the uploader.

Thanks!

[No9]

OK the plan here is to implement the file name convention as template using
https://github.com/bheisler/TinyTemplate
There will be a documented context object that contains the current params, a GUID and the namespace

limit_size - Core file size soft resource limit of crashing process"),
exe_name - The process or thread's comm value, which typically is the
                   same as the executable filename (without path prefix, and
                   truncated to a maximum of 15 characters)
pid - PID of dumped process, as seen in the PID namespace in which the process resides.",
signal - Number of signal causing dump.
timestamp- Time of dump, expressed as seconds since the Epoch."),
hostname (same as nodename returned by uname(2))"),
pathname - Pathname of executable, with slashes ('/') replaced by exclamation marks ('!'),
uuid - a unique id generated for this core dump
namespace - the namespace the pod is associated with.

The template will be configurable as a parameter in the chart
fileNameTemplate
And will default to the current format

{uuid}-dump-{timestamp}-{hostname}-{exe_name}-{pid}-{signal}

[No9]

Implemented in
4991693
f27156d
Will be packaged as part of.
https://github.com/IBM/core-dump-handler/projects/1#card-76263089