Red Hat and Fedora Leftovers

posted by Roy Schestowitz on Jul 24, 2026

• Red Hat ☛ The hidden cost of observability sprawl

  As Kubernetes adoption scales, platform teams often hit a painful wall: The exploding cost and complexity of telemetry. When trying to provide isolated service mesh observability for multiple development teams, the default reflex is often "hard tenancy". This provides strict, robust isolation to ensure that a malicious, compromised, or resource-heavy tenant cannot impact others. This means spinning up duplicated, entirely separate instances of Prometheus, Jaeger, and Grafana for every single tenant.

  While this brute-force approach achieves strict isolation, the compute overhead, storage costs, and operational nightmare of maintaining dozens of identical telemetry stacks quickly become unsustainable. Platform engineers spend their days managing infrastructure sprawl instead of delivering value, while cloud budgets skyrocket. There is a better way. By leveraging Kiali's (the console for Istio Service Mesh) advanced multi-tenancy capabilities, you can provide developers with the visual, intuitive observability they need to manage their CI/CD pipelines—without bankrupting your cloud budget or burning out your operations team.

• Red Hat ☛ Why your Hey Hi (AI) agent needs two sandboxes: Benchmark data

  In Layered sandboxing for Hey Hi (AI) agents: OpenShift and OpenShell, we argued that neither NVIDIA OpenShell nor Red Hat OpenShift sandboxed containers alone cover the full threat surface of an Hey Hi (AI) coding agent. OpenShell catches data exfiltration but can't stop kernel exploits. OpenShift sandboxed containers isolates kernel exploits but doesn't filter network traffic. Running both together addresses a wider range of threats than either one alone.

  That's the theory. Here's what actually happened when we tested it.

• Red Hat ☛ Optimize OpenShift workloads with software-defined memory

  As organizations deploy increasingly sophisticated AI, analytics, and entity-resolution workloads, they're discovering a common bottleneck: memory.

  Many modern applications are no longer constrained by CPU availability. Instead, they are limited by the amount of memory economically deployed within a single server or cluster. Whether you're processing electronic warfare (EW) signals, running large-scale graph analytics, or building Hey Hi (AI) inference pipelines, you will likely hit a "memory wall" long before you run out of CPU power.

• Red Hat ☛ Why is pytorch compile so fast?

  PyTorch's Inductor compiler automatically groups dependent operations together into single, efficient Triton kernels. This keeps data in faster memory close to the register and cuts down on kernel overhead. In this article, we'll look at an example of fusion, and you'll see exactly how torch.compile transforms your PyTorch operations into optimized GPU code.

  When you use PyTorch's compiler, your model runs up to 10x faster, but what's actually happening? Without compilation, the GPU runs a kernel (a function on the GPU) for each torch operation in your code. This causes things to slow down for two reasons: Time is spent moving data in memory, and there's overhead of starting each new kernel. Every time the GPU launches a kernel, it pays an overhead cost, and every intermediate result means writing to and reading from memory. This is where vertical fusion comes in, and why you need to understand how to use it.

• Tomas Tomecek: Onboarding packit upstream projects to fullsend (part 1)

  Red Hat Konflux team offers several Hey Hi (AI) agents via project fullsend. They triage issues, write patches, and review PRs (and more!) directly inside Microsoft's proprietary prison GitHub Actions.

  In Packit, we’ve decided to give Fullsend a try and onboard our python gitforge library ogr to it.