Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom / Templated Filenames #47

Closed
tjungblu opened this issue Jan 13, 2022 · 4 comments
Closed

Custom / Templated Filenames #47

tjungblu opened this issue Jan 13, 2022 · 4 comments
Assignees

Comments

@tjungblu
Copy link
Contributor

(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.

This was referenced Jan 13, 2022
@No9
Copy link
Collaborator

No9 commented Jan 13, 2022

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
Copy link
Contributor Author

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
Copy link
Collaborator

No9 commented Jan 18, 2022

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 No9 self-assigned this Jan 23, 2022
@No9
Copy link
Collaborator

No9 commented Jan 23, 2022

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

@No9 No9 closed this as completed Jan 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants