Design Administrative APIs for Enterprise Gateway

[lresende]

Customers have requested the ability to :

• List existing kernels per user
• List idle timeout for running kernels
• Ability to kill kernels
• etc

I would like to propose we start designing an ADMIN REST API for Enterprise Gateway, and implement the basic functionality described above.

As for security concerns, we could assume that at an initial point, we will trust the forward user (e.g. authenticated via KNOX) and we might investigate the notion of whitelisting administrators with an ADMIN role to restrict POST operations only to those.

[m0hit-aggarwal]

Hi @kevin-bates
I am interested in working on this. How can i start ?

[kevin-bates]

Hi @m0hit-aggarwal - thank you for your interest! I pulled up the PR you had provided last December and you're approach of using the kernel session manager was the right approach here. I think you'll find things much more straightforward as we no longer depend on Kernel Gateway and have control over the handlers.

I'm not sure if we should create a new endpoint (e.g., /api/kernel_sessions/, /api/sessions/kernels, /api/kernels/user, etc.) or add a query parameter to existing endpoints (e.g., /api/kernels?user=jdoe). The latter, of course, may provide an "adoption path" for existing front ends, but there are probably limits in what they could return. The latter also implies we'd need to plumb those changes into the gateway module of Notebook as well.

For this exercise, I'm inclined to create new endpoints keeping in mind how we might be able to adopt some of the returned values to existing endpoints by adding support for query parameters, etc. But I don't think we should let the existing endpoint behavior deter us.

What are your use cases/reasons for wanting this?

Do you use EG as a pure REST server and have your own front-end?

What kinds of information should we return?

Having the ability to gather this information both cumulatively as well as per user seems useful. Things like:

As an administrator, I need to quickly determine which kernels have been idle for long periods (sortable by idle time).
As an administrator, I need to quickly determine which kernels have been busy for long periods (sortable by busy time).
As an administrator, I need to quickly determine which kernels are close to being culled (based on the current culling configuration).
As an administrator, I need to quickly determine how many kernels a given user has running.
etc.,

Once we have metrics plumbed relative to kernels, we can include those as well.

Just from those use cases, I'm wondering if we have a general endpoint that can then take query parameters for state ({'idle', 'busy'}), user, ... (although we may want a separate endpoint for metrics).

Thanks again.

[m0hit-aggarwal]

Hi @kevin-bates
I am also in favour of creating new endpoints (e.g. /api/kernel_sessions, /api/kernels/user ) and along with that using existing API’s for gathering useful info.

Our use cases revolve around gathering generic info around the setup:

• Active, Busy, Idle Kernels
• Kernel lifetime
• Idle vs Busy time
• Kernel launch failures delimited by type of the errors (Launch Timeout, # kernels limit, Env issues etc.)
  etc.

We have been more interested in gathering information cumulatively rather than at user level but having information at user level also seems useful.

No, we don’t have our own front-end, we use JupyterLab as our front-end. I didn’t understand what you mean by EG as pure REST sever but we use EG to launch Spark IPython kernels.

I think we should first work on capturing metrics relative to kernels, as those could actually help us derive several other metrics. Later we could decide if we need general endpoint for other use cases.