feat(debug): make it possible to connect a remote ipython shell #900
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #900 +/- ##
==========================================
- Coverage 85.26% 85.19% -0.07%
==========================================
Files 284 285 +1
Lines 22332 22369 +37
Branches 3368 3371 +3
==========================================
+ Hits 19042 19058 +16
- Misses 2613 2637 +24
+ Partials 677 674 -3 ☔ View full report in Codecov by Sentry. |
jansegre
force-pushed
the
feat/shell-ipykernel
branch
2 times, most recently
from
30205ef to
79e13f4
Compare
jansegre
force-pushed
the
feat/shell-ipykernel
branch
from
79e13f4 to
049a33a
Compare
jansegre
force-pushed
the
feat/shell-ipykernel
branch
3 times, most recently
from
1c12222 to
c75a085
Compare
jansegre
force-pushed
the
feat/shell-ipykernel
branch
from
c75a085 to
c85ef3e
Compare
jansegre
force-pushed
the
feat/shell-ipykernel
branch
from
c85ef3e to
2410024
Compare
| @@ -120,6 +121,9 @@ def create_parser(cls) -> ArgumentParser: | |||
| help=f'Signal not support for a feature. One of {possible_features}') | |||
| parser.add_argument('--x-asyncio-reactor', action='store_true', | |||
| help='Use asyncio reactor instead of Twisted\'s default.') | |||
| # XXX: this is temporary, should be added as a sysctl instead before merging | |||
There was a problem hiding this comment.
Are we changing it in this PR?
There was a problem hiding this comment.
No, but in a future PR. On my initial conversation with @msbrogli we thought it would be better to do it in sysctl, allowing it to be turned on/off. However since turning it in/off requires somewhat more careful management of the IPKernelApp, and since there's a dependency on the asyncio-reactor which is easier to make explicit as a CLI parameter. I went with the current implementation as the initial proof of concept of this feature.
There was a problem hiding this comment.
Ok! Maybe we should update this comment, then? Just to prevent future confusion
Motivation
In many situations we don't have an API/sysctl to control or adjust what's happening on the fullnode. The ipython shell is a very useful escape hatch to freely tinker with the code. Currently there is a
shellsubcommand, which in practice is helpful to interact with the storage and consensus, but it doesn't really allow the node to keep running.Embedding an IPython kernel (aka ipykernel or ipkernel), allows a running node to be a server for a jupyter console (basically a remote ipython, either in a terminal or GUI), which basically provides a shell where all of the runtime can be accessed without stopping the node. This could even be used for debugging situations that are really hard to reproduce, but we could open a shell into a node where the case is happening.
Acceptance Criteria
--x-ipython-kernel(that currently depends on--x-asyncio-reactor) which enables ipython kernel in the fullnode using the mechanism expected by jupyter/ipython generating akernel.jsonon the data dir, which then allows a client to connect/disconnect freely to the shell usingjupyter console --existing /path/to/data/kernel.jsonChecklist
master, confirm this code is production-ready and can be included in future releases as soon as it gets merged