Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add activity watching to kernels #1827

Merged
merged 9 commits into from
Jan 24, 2017
Merged

Conversation

minrk
Copy link
Member

@minrk minrk commented Oct 11, 2016

adds to kernel REST model:

  • last_activity: datetime-aware timestamp
  • execution_state: from last recorded status message

related: jupyterlab/jupyterlab#1070

next PR: shutdown idle kernels

@minrk
Copy link
Member Author

minrk commented Oct 11, 2016

need to update a few tests to take the added timestamps into account

@parente
Copy link
Member

parente commented Oct 11, 2016

I just spotted this in the hackpad. Does it align with the activity tracking added to the kernel gateway a while back?

https://github.com/jupyter/kernel_gateway/blob/master/kernel_gateway/jupyter_websocket/swagger.yaml#L298

last_activity:
type: string
description: |
ISO 8601 timestamp for the last-seen activity on this kernel.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this explicitly be UTC?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are explicitly timezone-aware, and UTC as an implementation detail. I'll add that detail, though.

@minrk
Copy link
Member Author

minrk commented Oct 12, 2016

@parente I forgot about the KG activity API! This is significantly less than that:

  1. it only tracks a single activity stamp, not categories
  2. it's two added fields (last_activity, execution_state) in the kernels API, rather than a new API endpoint

Do you think we should pull in the KG API wholesale, rather than this simpler tracker? What have you used the more detailed information for?

@parente
Copy link
Member

parente commented Oct 12, 2016

Do you think we should pull in the KG API wholesale, rather than this simpler tracker? What have you used the more detailed information for?

I think the extra detail was added shotgun style because we didn't have our hands around everything that operators would want to know to make decisions about monitoring and shutting down kernels. At a minimum it'd be good to have the field names and types that are common match at least, even if the API is not 100% the same.

The original issue is here: jupyter-server/kernel_gateway#96

@rwhorman probably has more detail on what's used or not at the moment.

@yuvipanda
Copy link
Contributor

\o/ Can we use this from the hub too, thus taking out last activity tracking from the proxy?

"name": kernel.kernel_name,
"last_activity": kernel.last_activity,
"execution_state": kernel.execution_state,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woo!

@rgbkrk
Copy link
Member

rgbkrk commented Oct 24, 2016

This is so excellent to see.

@yuvipanda
Copy link
Contributor

yuvipanda commented Nov 10, 2016

jupyterhub/jupyterhub#857 is related, talks about adopting a standardized format for exposing white-box metrics (such as last-activity!).

@minrk minrk force-pushed the kernel-activity branch 2 times, most recently from 5d80a46 to 4826fe9 Compare November 18, 2016 10:59
@parente
Copy link
Member

parente commented Nov 22, 2016

Haven't heard back from @rwhorman on the comment above.

@jtyberg @lbustelo do either of you guys know if the activity tracking API proposed here vs the one with way more properties in the kernel gateway will satisfy existing use cases?

@enigmata
Copy link

@parente Nothing conclusive, as we're still experimenting and adjusting our model.

@minrk minrk force-pushed the kernel-activity branch 2 times, most recently from 48e7d07 to 26ec1bc Compare November 23, 2016 15:28
@takluyver
Copy link
Member

Heads up, this has a merge conflict.

@minrk
Copy link
Member Author

minrk commented Jan 13, 2017

Thanks, rebased.

@yuvipanda
Copy link
Contributor

yuvipanda commented Jan 13, 2017 via email

@takluyver
Copy link
Member

I'm hoping we might go straight to 5.0, because I'm getting tired of telling people that the new clipboard functionality (#1286) is not available yet.

@takluyver
Copy link
Member

What's the status of this? I'm trying to push towards a 5.0 release. Is this going to be mergeable fairly soon, or should we hold it for 5.1?

adds to kernel REST model:

- last_activity: datetime-aware timestamp
- execution_state: from last recorded status message
add /api/status endpoint for retrieving current status

includes

- started: start time of the server
- last_activity: latest activity across all endpoints
- connections: number of current connections
- kernels: number of current kernels
@minrk
Copy link
Member Author

minrk commented Jan 20, 2017

@takluyver fixing it now. I think it's in good shape, I just need to update the new tests to deal with the token changes.

@ivanov
Copy link
Member

ivanov commented Jan 21, 2017

The js/tree group for py3.5.1 build was stuck on Travis for 2 hours and 45 minutes without starting, so I stopped it and restarted it just now.

@minrk
Copy link
Member Author

minrk commented Jan 21, 2017

Thanks, @ivanov! Looks all green now.

I'm happy with it as-is now, but further reviews and ideas are always welcome.

@takluyver takluyver merged commit f5072cf into jupyter:master Jan 24, 2017
@blink1073
Copy link
Contributor

🎉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
5.0
Merged PRs
Development

Successfully merging this pull request may close these issues.

None yet

8 participants