IBM / core-dump-handler

Save core dumps from a Kubernetes Service or RedHat OpenShift to an S3 protocol compatible object store
https://ibm.github.io/core-dump-handler/
MIT License
131 stars 40 forks source link

Core dump generates random uuid instead of using pod uuid #147

Open paltaa opened 1 year ago

paltaa commented 1 year ago

Hello there! I've been testing this core-dump and noticed that the uuid is currently being generated. I was wondering if it would be possible to incorporate an option to get the pod uuid (with crioctl or kubectl) and add it to the file tamplate name.

I'm quite interested in contributing to this feature. Could you please let me know if you are currently accepting pull requests for new features? I would be more than happy to submit one if it aligns with the project's guidelines and requirements.

Thank you for your time and consideration!

No9 commented 1 year ago

Hey @paltaa Thanks for your interest in the project. The current guid used is unique to prevent core dumps from the same pod overwriting each other.

We are accepting PRs although action-rs is currently disabled by my org so the linting/unittests/clippy tests need putting directly into the GH Action.

Can I ask what the pod GUID is required for as it is available in the files that are generated with the core dump?

paltaa commented 1 year ago

Hey @No9

We are currently migrating our Kubernetes clusters from dockershim to containerd. As a result, our previous core-dump microservice is no longer compatible with dockershim. The issue lies in the fact that this core-dump microservice generated files in a specific structure, where the parent folder name utilized the pod GUID. Another service is responsible for linking the logs to the dump files based on this structure.

So, we can either add the functionality to this project or add a post processor after each of the files are uploaded to the bucket