Refactor datascience runtime Dockerfile environment variable management for ppc64le builds

[coderabbitai]

Problem Description

The current datascience runtime Dockerfile (runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu) has several issues with environment variable management for ppc64le builds:

Issues Identified

1. Build-only variables written to /etc/profile.d: Lines 30-37 write build-time variables like OPENBLAS_VERSION, ONNX_VERSION, and GRPC_PYTHON_BUILD_SYSTEM_OPENSSL to /etc/profile.d/ppc64le.sh, which persists them unnecessarily in the runtime image.

2. Variable duplication: OPENBLAS_VERSION=0.3.30 is defined both in /etc/profile.d/ppc64le.sh (line 33) and separately as ENV in the openblas-builder stage (line 165).

3. Unreliable sourcing: /etc/profile.d scripts are not sourced in non-login build contexts, making the approach unreliable for build steps.

4. Missing DRY principle: Version constants are duplicated across multiple stages instead of being centralized.

Current Code (Lines 30-37)

RUN if [ "$TARGETARCH" = "ppc64le" ]; then         echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh &&         echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh &&         echo 'export OPENBLAS_VERSION=0.3.30' >> /etc/profile.d/ppc64le.sh &&         echo 'export ONNX_VERSION=1.19.0' >> /etc/profile.d/ppc64le.sh &&         echo 'export PATH="$HOME/.cargo/bin:$PATH"' >> /etc/profile.d/ppc64le.sh &&         echo 'export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1' >> /etc/profile.d/ppc64le.sh;     fi

Impact Analysis

• Build reliability: Build-time variables may not be available when needed due to profile.d sourcing issues
• Image bloat: Unnecessary persistence of build-only variables in runtime image
• Maintenance overhead: Version updates require changes in multiple locations
• Code clarity: Duplicated definitions reduce maintainability

Solution Options

Option 1: Centralized ARG/ENV approach (Recommended)

• Define version constants as ARG near the top of Dockerfile
• Use ARG inheritance in downstream stages
• Remove /etc/profile.d writes for build-only variables
• Keep only runtime-needed PATH/LD exports

Option 2: Stage-specific ENV with build-time exports

• Use ENV in appropriate stages for versions
• Export variables locally in RUN steps where needed
• Minimize /etc/profile.d usage

Option 3: Hybrid approach

• Centralize versions as ARG
• Use local exports for build steps
• Selective /etc/profile.d for genuine runtime needs

Acceptance Criteria

• Version constants (OPENBLAS_VERSION, ONNX_VERSION) defined once as ARG
• Build-only variables not persisted to /etc/profile.d
• All builder stages use centralized version definitions
• Runtime-needed environment variables properly configured
• Build functionality preserved across all architectures
• Image size impact measured and documented

Implementation Guidance

1. Add centralized version ARGs:

   ARG OPENBLAS_VERSION=0.3.30
   ARG ONNX_VERSION=1.19.0

2. Update builder stages to use ARGs:

   FROM cpu-base AS openblas-builder
   ARG OPENBLAS_VERSION
   # Remove: ENV OPENBLAS_VERSION=0.3.30

3. Minimize /etc/profile.d usage:

   RUN if [ "$TARGETARCH" = "ppc64le" ]; then            echo 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' >> /etc/profile.d/ppc64le.sh &&            echo 'export LD_LIBRARY_PATH=/usr/local/lib64:/usr/local/lib:/usr/lib64:/usr/lib:$LD_LIBRARY_PATH' >> /etc/profile.d/ppc64le.sh;        fi

4. Use local exports in build steps:

   RUN export GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=1 && pip install ...

Related Files

• runtimes/datascience/ubi9-python-3.12/Dockerfile.cpu (primary)

Context

This issue was identified during PR #2215 review for ppc64le architecture support: #2215 (comment)