chore: upgrade to python 3.12 for crud-web-apps

[asaadbalum]

Description

Upgrades Python toolchain from 3.10 to 3.12 for all three CRUD web applications (Jupyter, Volumes, Tensorboards) and their shared common backend.

Closes #724, #725, #726

Changes Made

Dockerfiles

• Updated base image to python:3.12-slim for all three web apps
• Added explicit setuptools and wheel installation (required in Python 3.12 slim images)
• Files modified:
  • components/crud-web-apps/jupyter/Dockerfile
  • components/crud-web-apps/volumes/Dockerfile
  • components/crud-web-apps/tensorboards/Dockerfile

CI Workflows

• Updated Python version to 3.12 in:
  • .github/workflows/jwa_backend_unittests.yaml
  • .github/workflows/python_lint.yaml

Dependencies

Updated components/crud-web-apps/common/backend/setup.py to address security vulnerabilities:

• Flask: 1.1.1 → ≥2.3.2
• Werkzeug: 0.16.0 → ≥3.0.6
• requests: 2.22.0 → ≥2.32.4
• urllib3: 1.25.7 → ≥2.5.0
• kubernetes: ==22.6.0 → ≥22.6.0

Documentation

• Updated README files with Python 3.12 build instructions

Testing Performed

✅ CI Workflows (All Passed)

• JWA Backend Unit Tests
• Python Linting
• JWA Integration Test
• JWA Multi-Arch Build Test
• VWA Integration Test
• VWA Multi-Arch Build Test
• TWA Integration Test
• TWA Multi-Arch Build Test

✅ Local Functional Testing

Tested in Kind cluster with full Kubeflow deployment:

Infrastructure:

• Kind cluster with Istio gateway
• Full Kubeflow manifests applied
• All three web apps deployed with Python 3.12 images

CRUD Operations Verified:

• ** For each app:**
  • ✅ Created an instance successfully
  • ✅ Viewed the instance successfully
  • ✅ Deleted the instance successfully

Additional Verification:

• ✅ API endpoints responding properly
• ✅ Container health checks passing
• ✅ Application logs clean (no Python compatibility errors)
• ✅ All pods running and ready

Acceptance Criteria

• Docker images build successfully on Python 3.12
• Backend unit tests pass on Python 3.12
• Integration tests pass with Python 3.12 images
• Multi-arch builds (amd64, arm64, ppc64le) complete successfully
• All files checked for additional Python version dependencies
• Security vulnerabilities in dependencies addressed
• Manual functional testing completed

Notes

• Python 3.12 slim images no longer include setuptools and wheel by default, so explicit installation was added
• All dependency version constraints were updated to minimum required versions (using ≥) for better flexibility
• The kubernetes package constraint was relaxed from ==22.6.0 to ≥22.6.0 to allow compatible updates

[yehudit1987]

The current python_requires=">=3.6" is incompatible with the updated dependencies. I checked the actual Python requirements on PyPI:

Dependencies that require Python ≥3.9:

• urllib3 >= 2.5.0 → requires Python ≥3.9
• gevent (latest) → requires Python ≥3.9

Dependencies that support Python ≥3.8:

• Flask >= 2.3.2 → requires Python ≥3.8
• Werkzeug >= 3.0.6 → requires Python ≥3.8
• requests >= 2.32.4 → requires Python ≥3.8
• kubernetes >= 22.6.0 → requires Python ≥3.6

Recommendation:

Since this PR was tested with Python 3.12 and some dependencies require ≥3.9, I suggest:

python_requires=">=3.12", # Tested version, most conservative Or at minimum:

python_requires=">=3.9", # Minimum required by urllib3 2.5.0 and gevent (that is the permissive suggestion).

Also consider removing line 13:

"importlib-metadata >= 1.0;python_version<'3.8'",
This condition will never be true when python_requires is ≥3.9, making it redundant.

[asaadbalum]

Great observation, totally agreed and modified, thanks.

[yehudit1987]

/lgtm
Thanks Asaad.

[andyatmiami]

Thanks @asaadbalum - this is looking really good - just a little more cleanup I'm suggesting here.

---

In addition to included review comments - please also be mindful of changes needed to this file:

• https://github.com/kubeflow/notebooks/blob/notebooks-v1/components/crud-web-apps/common/README.md#how-to-use

We should make sure that we are referring to 3.12 in the example Docker snippet.

---

I also think we should clean up some deprecated code as part of this work too. The following lines should use log.warning (as opposed to the deprecated log.warn)

• https://github.com/kubeflow/notebooks/blob/notebooks-v1/components/crud-web-apps/common/backend/kubeflow/kubeflow/crud_backend/config.py#L62
• https://github.com/kubeflow/notebooks/blob/notebooks-v1/components/crud-web-apps/common/backend/kubeflow/kubeflow/crud_backend/__init__.py#L26

We can see log.warning already being employed in the codebase - including - but not limited to - here:

• https://github.com/kubeflow/notebooks/blob/notebooks-v1/components/crud-web-apps/common/backend/kubeflow/kubeflow/crud_backend/authz.py#L63

[andyatmiami]

I THINK the following file is unused.. and given the changes here to setup.py - is now a source of outdated (mis)information:

• https://github.com/kubeflow/notebooks/blob/notebooks-v1/components/crud-web-apps/common/backend/kubeflow/kubeflow/crud_backend/requirements.txt

We should remove this requirements.txt file (assuming its removal doesn't break anything!)

[andyatmiami]

Suggested change

	- name: Set up Python environment 3.12
	- name: Set up Python

shorter name == better name 😎

I want to get out of specifying the version in the name to reduce number of lines that would ever need changes on future update..

[andyatmiami]

/ok-to-test

[thesuperzapper]

We must pin the version of the kubernetes Python client, otherwise we don't know what version we are using, and what Kubernetes versions it supports, I have made this change in: 5204943

Once I did this, it became clear that we were not using the version of kubernetes that we expected, because kubernetes introduced a constraint on older urllib3 at some point, making our stated requirement incompatible and failing builds. Because we should just use whatever latest requests and urllib3 that work with the direct dependencies, I have removed their version constraints in e7b1f79

[thesuperzapper]

Whenever we cut a release, we can do more thorough testing, in addition to the testing that's done automatically in the manifest repo, but I imagine anything that breaks would be pretty obvious.

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thesuperzapper

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [thesuperzapper]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment