gsoc: Add End-to-End ARM64 Support & Validation on Kubeflow for GSoC 2026 proposal (#4299)

* gsoc: Add a new proposal for End-to-End Arm64 support and validation on Kubeflow into GSOC 2026

Add a new proposal for End-to-End Arm64 support and validation on Kubeflow into GSOC 2026

Signed-off-by: Jeffery T. (mrdojojo) <113143099+jtu-ampere@users.noreply.github.com>
Co-Authored-By: Andrey Velichkevich <andrey.velichkevich@gmail.com>

* Re-trigger CI

Signed-off-by: Jeffery T. (mrdojojo) <113143099+jtu-ampere@users.noreply.github.com>

* Re-trigger CI

Signed-off-by: jtu-ampere <113143099+jtu-ampere@users.noreply.github.com>
Signed-off-by: Jeffery T. (mrdojojo) <113143099+jtu-ampere@users.noreply.github.com>

* Re-trigger CI

Signed-off-by: Jeffery T. (mrdojojo) <113143099+jtu-ampere@users.noreply.github.com>

---------

Signed-off-by: Jeffery T. (mrdojojo) <113143099+jtu-ampere@users.noreply.github.com>
Signed-off-by: jtu-ampere <113143099+jtu-ampere@users.noreply.github.com>
Co-authored-by: Andrey Velichkevich <andrey.velichkevich@gmail.com>

Author: jtu-ampere

content/en/events/upcoming-events/gsoc-2026.md

@@ -162,6 +162,76 @@ Tracking issue: [kubeflow/katib#2605](https://github.com/kubeflow/katib/issues/2
 * Basic understanding of machine learning training workflows
 * Experience with HPO frameworks
 
+---
+## Project #: End-to-End ARM64 Support & Validation on Kubeflow
+
+**Components:** Manifests (Platform), Kubeflow Pipelines (KFP), Katib, Notebooks, Trainer
+
+**Mentors:** @chasecadet, @jtu-ampere (Mentor) 
+
+**Owning Team:** ARM Contributions Team 
+
+**Contributor:** 
+
+**Details:**
+
+**Context & Vision:**
+ As development teams increasingly move to Apple Silicon ([M-series chips](https://en.wikipedia.org/wiki/Apple_silicon#M-series_SoCs)) and production workloads shift to cost-efficient ARM-based cloud instances (like [OCI Ampere](https://www.oracle.com/cloud/compute/arm/), [Google Axion](https://cloud.google.com/products/axion), and [AWS Graviton](https://aws.amazon.com/ec2/graviton/) ), ARM64 support is a critical requirement for the future of Kubeflow.
+
+Currently, support is fragmented. The ARM Contributions Team aims to close this gap by establishing First-Class Citizen support for ARM64 across the entire Kubeflow Reference Platform. This initiative is not just about compiling binaries; it is about validating the "Kubeflow Platform" experience to ensure it is robust, reproducible, and ready for diverse environments.
+
+**Strategic Alignment:**
+This work directly supports the Kubeflow Platform Definition. By validating the end-to-end platform on non-x86 architectures, the team serves as a critical quality gate, ensuring that "Kubeflow" remains a consistent standard regardless of the underlying hardware.
+
+**Collaboration & History:**
+
+This project builds upon the extensive groundwork laid by the ARM Support Team, who have previously validated and built many of these images. The goal is to upstream this foundational work—porting validated Dockerfiles, build flags, and image tags into the official Kubeflow repositories—effectively making the community's "best effort" success the official standard.
+Scope & Deliverables
+
+**Scope & Deliverables:**
+1. Multi-Arch Build System (CI/CD)
+
+    **Audit & Standardization:** The team will identify every container image in the official kubeflow/manifests release that lacks an ARM64 variant.
+
+    **Pipeline Implementation:** Update build systems (GitHub Actions/Prow) to generate multi-arch manifests (AMD64/ARM64) automatically on release. The goal is a single tag (e.g., :v2.0.0) that pulls the correct image for the host architecture.
+
+2. Platform Manifest Validation
+
+    **Architecture Agnosticism:** Ensure official Kustomize manifests do not hardcode architecture-specific SHA hashes or incompatible image tags, ensuring the manifests apply cleanly regardless of the node architecture.
+
+3. Infrastructure: Cloud & Edge
+
+    **Cloud Validation (OCI):** Leverage Oracle Cloud Infrastructure (OCI) Ampere A1 instances to maintain a persistent "Golden" test environment.
+
+    **Stretch Goal:** On-Premise & Edge Demonstration: A key stretch goal for this team is to demonstrate Kubeflow running on on-premise ARM hardware.
+
+    **The "Why":** This serves as the ultimate proof of Kubeflow's portability. By successfully deploying to an edge environment (outside of managed cloud services), we demonstrate that Kubeflow is truly infrastructure-agnostic and ready for Edge AI use cases.
+
+4. End-to-End (E2E) Platform QA
+
+    **Full Suite Testing:** Run the full Kubeflow End-to-End test suite on ARM infrastructure to catch architecture-specific bugs (e.g., generic libc dependencies, JIT compiler issues in TensorFlow/PyTorch).
+
+    **Documentation & "Golden Data":** Generate a "Golden Data" set of known-good configurations for running Kubeflow on ARM. This includes documentation on "gotchas" for users running local development clusters on Apple Silicon (Kind/Minikube).
+
+**Difficulty:** Medium/Hard (Depends on CI/CD complexity) 
+
+**Size:** 350 hours
+
+**Tracking & References:**
+   
+* KFP Issue: [Build and publish ARM images for KFP #10309](https://github.com/kubeflow/pipelines/issues/10309)  
+* Manifests Issue: [Support for the aarch64 architecture #2745](https://github.com/kubeflow/manifests/issues/2745)
+
+**Team Capabilities & Stack:**
+
+* Docker/Containerization: Deep understanding of multi-arch builds (docker buildx, manifests).
+* CI/CD: GitHub Actions (primary), Prow (secondary).
+* Kubernetes: Kustomize, Manifest management.
+* Go/Python: Ability to debug build scripts and genericize code that assumes x86 architecture.
+* Infrastructure: Familiarity with cloud instances and bare-metal/edge hardware configuration.
+
+
+
 ### Project 3: KServe Models Web Application
 
 **Components:** Kserve, Kubeflow Common Library, Kubeflow Dashboard