Uploaded image for project: 'Red Hat OpenShift AI Engineering'
  1. Red Hat OpenShift AI Engineering
  2. RHOAIENG-911

Improve Legacy 'Jupyter' Single Namespace (Decommission/Rework)

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • Dashboard
    • Single Namespace Decommission
    • False
    • Hide

      None

      Show
      None
    • False
    • To Do
    • RHOAIENG-2740Improve Released Features Experience
    • 25
    • 25% 25%

      Description / Background

      We have an application in the Dashboard called Jupyter. The functionality of this tab is designed to use a single K8s Namespace to store all resources created by the client code. This combines all users who use the application to share a namespace for their personal resources... which causes a permission concern. Around this concern we excluded permissions to all regular users and put a service account in the Dashboard to manage the resources on their behalf.

      Due to this infrastructure, the code requires unique security and separate code to manage the lifecycle of the code. Since the addition of Data Science Projects, we are now duplicating a lot of the same functionality to create Notebooks (now called Workbenches) and the associated resources.

      Primary Goal

      The goal is to try and take this Jupyter "Single Namespace" concept and convert it over to the DS Projects way of doing things, by giving each user a K8s Namespace (aka Project) for their own resources.

      Main Concerns

      We need to be aware of a few things when we go to tackle this effort:

      • We need to be sure to keep the simplistic and guided flow of the Jupyter tile – UX will need to be involved to help us make this happen
      • We need to create & manage the namespace we need for each user – this probably needs some discussion
      • We need to support types of user permissions
        • Users with full access – admins / cluster-admin of k8s
        • Users with self provisioner
        • Users whom are given a project, but cannot create one – think Dev Sandbox
        • Users who have no projects and cannot create them – think classroom setting
      • There is a heavy lean on K8s permissions & we should use the pass-through API for this
      • Partial or full removal of the related (to the Jupyter tile) backend code should come with this effort – it's code duplication and serves nothing but to cause bugs / security concerns

            Unassigned Unassigned
            aballantyne Andrew Ballantyne
            RHOAI Dashboard
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: