spark-operator: Update Notebooks integration to use Enterprise Gateway 3.3.0 defaults

[Ramneek-kalra]

Summary

Updates the Integration with Kubeflow Notebooks guide so the Jupyter Enterprise Gateway install matches current chart defaults and the latest release.

Fixes: #

Motivation

The current docs pin Jupyter Enterprise Gateway to 3.2.3 and ask readers to deploy with a custom values.yaml. That custom config, plus the PVC / hostPath kernelspecs mount path, caused real install friction: mounted kernelspecs were not detected reliably.

The Enterprise Gateway Helm chart already:

• Ships elyra/enterprise-gateway:3.3.0 and elyra/kernel-image-puller:3.3.0
• Includes spark_python_operator in kernel.allowedKernels
• Keeps kernelspecsPvc.enabled: false by default

So the docs should install with chart defaults and avoid recommending PVC-mounted kernelspecs for the common path.

Changes

• Bump Helm chart / image references from 3.2.3 → 3.3.0
• Replace the custom enterprise-gateway-helm.yaml install with the default chart install (no --values override)
• Optionally note --set kernel.defaultKernelName=spark_python_operator if readers want that kernel as default
• Remove (or clearly de-emphasize) the PVC / hostPath kernelspecs customization steps
• Point advanced customization to the upstream Jupyter Enterprise Gateway docs
• Correct the kernel name in the “what happens next” steps to spark_python_operator (was pyspark)

Test plan

• Preview the page locally (or via Netlify/preview if available) and confirm Step 1 shows only the default Helm install for v3.3.0
• Confirm there is no custom values YAML required for the happy path
• Confirm the PVC kernelspecs section is removed or marked as not recommended
• Confirm remaining download/image URLs use 3.3.0
• Confirm “select kernel” text uses spark_python_operator
• Manually verified Helm install against a cluster using chart defaults (optional but recommended):

helm upgrade --install enterprise-gateway \
  https://github.com/jupyter-server/enterprise_gateway/releases/download/v3.3.0/jupyter_enterprise_gateway_helm-3.3.0.tar.gz \
  --namespace enterprise-gateway \
  --create-namespace \
  --wait

[google-oss-prow]

Hi @Ramneek-kalra. Thanks for your PR.

I'm waiting for a kubeflow member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign yuchaoran2011 for approval. For more information see the Kubernetes Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• content/en/docs/components/spark-operator/OWNERS

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

[github-actions]

🚫 This command cannot be processed. Only organization members or owners can use the commands.

[Ramneek-kalra]

Hi @yuchaoran2011 — could you take a look when you have a chance, and /ok-to-test if this looks reasonable?

[github-actions]

🚫 This command cannot be processed. Only organization members or owners can use the commands.

[Arhell]

/ok-to-test

[thesuperzapper]

I think we should probably not suggest people use the enterprise_gateway now that Kubeflow SDK has a direct integration with spark operator:

• https://sdk.kubeflow.org/en/latest/spark/index.html
• https://github.com/kubeflow/sdk/tree/main/proposals/107-spark-client

Lets discuss this in slack about how we can update the "how to integrate notebook and spark operator" to use the SDK.

[Ramneek-kalra]

@thesuperzapper > Few questions as I tried exploring SDK today as per the use-case we need and what kind of things might differ from not using Jupyter Enterprise Gateway:

Use-Case:

• Our users want to connect to DB and using PySpark Module over that for which we tried using custom image with JAVA on the Path + PySpark package already mounted > Which worked as expected, though we don't want to depend on Custom-Image and use under Kubeflow Notebook (Not good UI Experience)

What we tried today?

• Removed Jupyter Enterprise gateway completed and with spark-operator > Unsure how we can use Spark SDK as it's failing at:

from kubeflow.spark import SparkClient

# Connect to a Spark cluster
client = SparkClient()

spark = client.connect(
    num_executors=5,
    resources_per_executor={
        "cpu": "2",
        "memory": "2Gi",
    },
)

# Create a distributed DataFrame
df = spark.range(10)

# Run a distributed computation
df.show()

Questions:

• As you know the use-case now, guide me if I need Spark-Cluster to invoke SparkSession/SparkApplication to run PySpark based code.

Looking forward to hearing from you next. Thanks!

[juliusvonkohout]

@vikas-saxena02 who will present it at the Kubeflow virtual event. We will remove the enterprise gateway and replace it with the official SDK way.

[juliusvonkohout]

/close

[google-oss-prow]

@juliusvonkohout: Closed this PR.

Details

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[juliusvonkohout]

@vikas-saxena02 may you replace the enterprise gateway with the official way in the documentation ?

[vikas-saxena02]

I think we should probably not suggest people use the enterprise_gateway now that Kubeflow SDK has a direct integration with spark operator:

• https://sdk.kubeflow.org/en/latest/spark/index.html
• https://github.com/kubeflow/sdk/tree/main/proposals/107-spark-client

Lets discuss this in slack about how we can update the "how to integrate notebook and spark operator" to use the SDK.

Hi @thesuperzapper , i 100% agree with you and for scala users Apache Toree as a kernel introduces a lot of vulnerabilities in the overall solution. I am, presenting a talk in Kubeflow Virtual Syposium where I am presenting SparkConnect as the alternative where we can use Almond and have users use that as an out of box solution. This way we will cut dependency on jupyter enterprise gateway for sure. if I can get some guidance on how to present it as a proposal to wider community, it would be of great help. PS: Julius already know about the solution. cc: @chasecadet @andreyvelich @nabuskey @franciscojavierarceo @vjanelle

[juliusvonkohout]

@vikas-saxena02 Once the test in the community distribution is there you can mostly delete theis page and just link to the test.

[juliusvonkohout]

@vikas-saxena02 Once the test in the community distribution is there you can mostly delete theis page and just link to the test.

[vikas-saxena02]

@vikas-saxena02 Once the test in the community distribution is there you can mostly delete theis page and just link to the test.

@juliusvonkohout i was thinking of doing a proper documentation as this is valid usecase for many people. think its better to do a proper documentation and then will provide link to the tests as well.

[juliusvonkohout]

Documentation has to be maintained at costs and automation is the best documentation. So please keep it short and focus on the high level then and for the implementation link to the test.