I’m playing catchup as I’ve missed several sessions, but I just found out that if you have Spotify Premium you can listen to the audio book there, narrated by the author 😄

https://open.spotify.com/show/55TTvaNnANPbUAyqFuoPjJ?si=KGAjgiszTq-vriPJg6V1Bw

Here are the other projects I own:

• Project name - Pairify
• Purpose - Automatically generates pairing issues on GitLab.com from Slack conversations
• Current owner(s) - @anton
• Backup owner(s) - @benjaminking @kballon
• Repository/Location - https://gitlab.com/gitlab-com/support/toolbox/pairify
• Dependencies - None, although other tooling relies on it
• Maintenance frequency - Monthly
• Criticality - High - this automates a mundane repetitive task

• Project name - Zendesk Download Router
• Purpose - A cross browser extension that routes downloads from Zendesk into separate folders
• Current owner(s) - @anton
• Backup owner(s) - No backup owners
• Repository/Location - https://gitlab.com/gitlab-com/support/toolbox/zd-dl-router
• Dependencies - None
• Maintenance frequency - Quarterly
• Criticality - High - this automates a mundane repetitive task. Do note that half the monthly users for this extension originate outside of GitLab.

• Project name - filtered-categories-yml
• Purpose - A scheduled pipeline that extracts category names and descriptions from GitLab's categories.yml file for use in the FY26 Q2: Closure habits pilot (support-team-meta#6835).
• Current owner(s) - @anton
• Backup owner(s) - @jgianoutsos
• Repository/Location - https://gitlab.com/gitlab-com/support/toolbox/filtered-categories-yml
• Dependencies - The categories.yml file
• Maintenance frequency - Rarely
• Criticality - Critical - it is required for the Glean product category prompt in Zendesk.

Some quick examples I found in Zendesk, so there is clearly a need:

• https://gitlab.zendesk.com/agent/tickets/683504 - Customer says they were asked to run GitLabSOS plus a sanitizer but, due to the nature of their data, they need a detailed explanation of what is captured, since "any and all logs and config files need to be sanitized such as Names, IP, MAC address, URL, Project Names, Unique identifiers, Buzz words, etc.
• https://gitlab.zendesk.com/agent/tickets/611737 - Customer operates in an air gapped and highly restrictive environment and states they are unable to provide log bundles without greater sanitizing efforts. If logs from GitLabSOS are needed, Support should advise which subset to extract.
• https://gitlab.zendesk.com/agent/tickets/692302 - Customer provides SOS archives where logs have been processed by Red Hat's SOS tool and wants us to confirm if they are usable by Support.
• https://gitlab.zendesk.com/agent/tickets/676690 - Customer asks which specific files from GitLabSOS are crucial for failure analysis and raises implied concerns about how much is collected.
• https://gitlab.zendesk.com/agent/tickets/602886 - Customer wants to provide a GitLabSOS report but is concerned it collects alot of information such as IP Address, Host DNS, Gitlab logs (auth_json and others) with username, user email, user dn, clinet IP, remote ip etc.

@oli.campeau @grantyoung Thank you for sharing the Cloud Native reference architecture docs, this is very helpful.

To give you some further context, we have ALOT of customers running a single Gitaly pod in Cloud Native. Some of those customers are experiencing performance issues due to the default resource pod limits being hit and they needed to vertically scale up to resolve the performance issues. This led to the creation of this KB article: High Gitaly CPU Load in Kubernetes

With that in mind, I have the following questions:

1. Do we also need to provide some recommendations for right size Pod resources for the Cloud Native reference architectures?
2. The smallest reference architecture (Small) recommends 3 Gitaly pods which would be sharded Gitaly. Does this mean that if a customer only has a single Gitaly pod in Cloud Native, that it would be classed as a deviation? In other words, would we support Cloud Native environments with 1 Gitaly pod?
3. From the Gitaly team's perspective - if a customer is experiencing performance issues with a single Gitaly pod, is it better to advise customers to increase the resource Pod limits, or add another Gitaly pod as another shard and move repositories over to it? I realise this is a very open ended question, but this will definitely be a question that customers will ask as their Cloud Native environments grow in usage and it might be good to document a recommendation somewhere.

If I should be raising these questions elsewhere do let me know 🙂

@jfarmiloe This is a great observation and I agree. I was thinking to change the prompt to this:

- | **Staleness** | No meaningful activity from **GitLab product/engineering team** (comments, label changes, related MRs) in the **last 30 days**. Activity from Support Engineers, Solution Architects, Customer Success Managers, Account Owners, or customers does NOT reset staleness. |
+ | **Staleness** | No comments from Backend/Frontend Engineering (exclude Customer Support) in the **last 30 days**. |

I am yet to test this, but I am unsure if the agent is smart enough to look up the job titles on user profiles 🤔

Thanks John, that is super helpful to know. The SOS tool by Red Hat appears to be open source and written in Python.

Here is the relevant code: https://github.com/sosreport/sos/blob/34329172acab29d4ddf316cbd989cb7eae13ddb6/sos/cleaner/__init__.py

@howellsm That's a bit strange, if you have a GitLab plan can you contact GitLab Support and we can help you. Please feel free to mention me by name in the ticket 🙂

@mbobin Ah sorry, I followed !207768 (comment 3091580418) and got confused 😅

I'll get this sorted next week.

cc @jagood just FYI 🙂