I have a test environment with a 1G memory limit and can reliably make the jupyter kernel fail in this environment at the gridsearch call as a result of limited memory (VM with 1G and running Jupyter inside a Docker container, mainly for simplified Jupyter setup). For reference, here's the startup line for docker (the notebook is loaded manually on the jupyter ui):
Aug 29 2017
Aug 22 2017
Thanks for the suggestion. I'll run a test with more limited RAM. BTW, is there any status/monitoring to observe jupyter kernel status from a notebook user end? I haven't found anything yet.
Aug 17 2017
The tools project contains a list of all the instances. This includes the k8s nodes, grid workers, and PAWS fabric. This doesn't appear to include the nodes referenced above or their monitoring. Likely the separate PAWS project is the new platform being set up to isolate contention in T167086.
Aug 16 2017
Aug 14 2017
K8s quotas are implemented with a per-namespace ResourceQuota object. See k8s quota documentation.
Aug 12 2017
Aug 9 2017
Jul 25 2017
Have often found number of unique log ins to a systems per month to be a useful stat: (Drop the wc to see the distribution of logins per user.)