Codecov Report

Attention: Patch coverage is 40.00000% with 6 lines in your changes missing coverage. Please review.

Please upload report for BASE (main@21bfcd7). Learn more about missing BASE report.

@@           Coverage Diff           @@
##             main    #3299   +/-   ##
=======================================
  Coverage        ?   83.74%           
=======================================
  Files           ?      158           
  Lines           ?    19939           
  Branches        ?      505           
=======================================
  Hits            ?    16698           
  Misses          ?     3057           
  Partials        ?      184           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I am now using the AWS S3 envs in Elyra itself, if, and only if, KUBERNETES_SECRET auth_type is used.
I am also now not requiring, pre-save of runtime config, the fields cos username and cos password when auth_type is KUBERNETES_SECRET. Instead, I require in that case that the AWS S3 envs be present.

Nice progress @shalberd , make sure you consider and validate the scenario where users are running Jupyter from their laptops and submitting the pipelines to hosted environments on Kubernetes-based runtimes such as kubeflow, this is an important use case/scenario.

@lresende does Kubeflow pipelines also work with Git integration, or with direct api calls? Elyra-speaking, I mean.
I assume Kubeflow running on K8S uses S3 for pipeline .tar.gz exchange between Elyra and the runtime as well, correct?

@harshad16 @lresende @caponetto @jiridanek Ok, so I built from my fork branch an Elyra wheel file and tested it with Jupyterlab 4.x and an Airflow runtime config.
Before I started the workbench / jupyterlab, I supplied env vars.
You can do that, supply the two env vars, with docker run and podman run as well, or on your local system if running non-dockerized,
but here is what that looks like in the podSpec for the lab container, either via env, but in this case, with envFrom section that references the elyra cos K8S secret as it is in the jupyterlab workbench namespace.
patched kind: Notebook envFrom:

As a result of that kind: Notebook podSpec container env reference, I now see the env vars from the K8S secret as env vars of my workbench:

Container envFrom section in Openshift / K8S:

Jupyterlab 4.2.7

Checking envs present in system, in jupyterlab terminal:

[1001350000@jupyter-2025-sven-test-0 ~]$ env | grep AWS
AWS_SECRET_ACCESS_KEY=5HCCCBBBYCP0Fbu65VAxxxxxZZZZZTTTTWVtmRT1
AWS_ACCESS_KEY_ID=6rXXxxxxxZZZtttTZZZ3eZ

runtime section, note, with COS auth type KUBERNETES_SECRET and only k8s cos secret name entered. Saving does not yield any errors when cos username and cos password are empty, as intended.

Running an Airflow generic pipeline works, too

e.g. I submit it to my Airflow (Elyra will upload tar.gzip to S3, write DAG Code to Gitlab / Github):

sucess: pipeline submitted, Elyra used env vars for communicating with S3:

Testing case when no env vars present in Jupyterlab when using auth type KUBERNETES_SECRET:
To delete the env vars, you have to restart jupyterlab / the workbench and essentially not provide the env vars anymore. This is how I do that in ODH Dashboard, but you can think of the same for running locally or dockerized. With docker, you just would not pass the env vars, locally, you would unset the env vars on your system.


295)
no more AWS env vars in jupyterlab workbench container.

Because the pod Spec section changed, notebook restarts.
Now, in the runtime config, for auth type KUBERNETES_SECRET, Elyra on save of the runtime config complains that the AWS envs vars are not present.

Terminal in Jupyterlab tells us the same:

[1001350000@jupyter-2025-sven-test-0 ~]$ env | grep AWS
[1001350000@jupyter-2025-sven-test-0 ~]$

The two other cloud object storage authentication types require the same fields as always; no change there on runtime config save button click: