-
Notifications
You must be signed in to change notification settings - Fork 3
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
[ENH]: Guided create bucket finalized #33
Conversation
Oh, and I haven't tackled how we want to handle the start_jupyter command yet. |
When a user enters a local path for mounting, should we check to make sure it exists? |
Yes, and we can't in general create that directory ourselves due to how it
works for docker toolbox.
…On Tue, Jun 11, 2019, 08:05 Leslie Lamarche ***@***.***> wrote:
When a user enters a local path for mounting, should we check to make sure
it exists?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#33?email_source=notifications&email_token=ABDEHE77VEZD7MFCN7LJCVDPZ65MTA5CNFSM4HWZL4CKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNODYY#issuecomment-500883939>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABDEHE7NBZHE7V4RQCGQ2D3PZ65MTANCNFSM4HWZL4CA>
.
|
Sounds good. Also, just a stylistic thing, but would anyone be bothered if we make jupyter lab the default for start_jupyter? Jupyter lab starts when you choose yes at the end of the create_bucket sequence, so it would probably make sense. |
Minor problem found.
I'm working it. Edit: Context: The "problem" here is that this doesn't match the server experience. On the server, |
…orkspace, updated mount message
Next on the list:
|
Finally done and ready for testing. |
@ljlamarche, can you test this and merge if it works? Please start by removing any buckets you already have running. |
After this is merged, we need to update usage docs in #31 |
@asreimer I am experiencing a bug:
Everything is working great.
|
That output is meaningless to me. You'll need to debug this on your end. |
Well, don't worry about the output. The resen tool just hangs after stop_jupyter. When I start and stop jupyter (not guided command) everything works fine |
Ok, but why is it hanging? It works perfectly on my system. |
Yes, it hangs, i.e. no more command prompt. Some other resen tool comments:
|
This branch works perfectly in Windows 10 with Docker Toolbox. |
I fixed the double stop_jupyter error. It was simple. I can't debug/fix the hanging problem you are experiencing with the information you have provided here. It also doesn't happen on my Windows 10 machine, so you have to figure this out. We'll see if @ljlamarche also has the problem or not. |
@asreimer Sure. I'll try to see what is really happening. I will also test it in a linux server machine |
On linux I am getting another error when entering the local path:
Linux: 4.4.0-141-generic #167-Ubuntu SMP Wed Dec 5 10:40:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Now, if I try using |
Ok, I had a chance to test this. I have not been able to reproduce the hanging issues that @pmreyes2 keeps running into at all... The only issue I had was
I think we just need to replicate whatever check is in
(@asreimer , did you already fix the double error issue? Regardless, I think this is really NOT a big deal right now.) Aside from that, there were just a couple really minor cosmetic things from the user interface perspective:
vs
Other than that, this looks great! |
resen/resencmd.py
Outdated
@@ -190,29 +174,52 @@ def do_status(self,args): | |||
|
|||
def do_start_jupyter(self,args): | |||
"""Usage: | |||
>>> start_jupyter bucket_name local_port bucket_port\t: Start a jupyter notebook server on port bucket_port available at local_port. | |||
>>> start_jupyter bucket_name local_port bucket_port --lab\t: Start a jupyter lab server on port bucket_port available at local_port. | |||
>>> start_jupyter bucket_name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doc string should conform to the format of similar commands.
start_jupyter bucket_name : Start jupyter on bucket bucket_name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
status = self.program.start_jupyter(bucket_name,local_port,bucket_port,lab=lab) | ||
# get bucket infomrmation (ports and status) | ||
# This stuff may be better suited to exist in some kind of "status query" inside of Resen.py | ||
ind = self.program.bucket_manager.bucket_names.index(bucket_name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the issue with the start_jupyter
command. Checking to make sure that a bucket name exists happens in self.program.start_jupyter()
on line 208, which is consistent with what's going on with stop_jupyter
, but we're trying to get the port information up here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Ok, I looked into the
|
@pmreyes2 and I figured out how to reproduce the hanging issue (at least on my mac). The problem occurs when you start a jupyter session and then actually DO something in the session. I wasn't getting the issue before because I was just checking that the jupyter page opened in my browser. To reproduce the problem:
This hangs. This behavior seems to happen regardless of whether you start jupyter by entering |
@pmreyes2 are you using your own fork to do the testing? It's very strange that you are the only one getting stuck. And it's even stranger that on your Mac it's getting stuck at the "ps -ef" execute command statement. Is that the same place it's getting stuck on the Ubuntu server (you didn't indicate that it's the exact same problem)? I'll fix the other problems. @ljlamarche I have already fixed the double stop_jupyter problem. @pmreyes, the pathlib problem you encountered seems to be some problem with the pathlib version on python 3.5. Can you please post the output of pip freeze so we can check versions of pathlib? |
Ok, that's actually useful for debugging. Thanks for digging. |
@ljlamarche @pmreyes2 define "do something"? I tried 1+1 in a py36 notebook. I cannot reproduce the problem. Here's what I did:
and
no hanging. I don't get a hang on Windows 10. I don't get a hang on Fedora 29 (my laptop). I cannot reproduce this. When I come in you will have to show me what you are doing. edit: it doesn't matter what I "do" in the jupyter server, nothing hangs it... |
I have now fixed the crashing that occurs with start_jupyter when supplied with a non-existent bucket name. I think I have fixed the pathlib problem that @pmreyes2 encountered on his ubuntu server. Can @ljlamarche and @pmreyes2 confirm? |
start_jupyter random_name test:
Its fixed. |
I duplicated this:
In the "normal" case (when I don't start a new notebook), entering I think we'll just have to show this to you when you get in - It looks like it's a weird mac thing. |
@ljlamarche Also, yes, 2019.1.0rc2 is available on dockerhub now, but let's worry about that after we get this PR sorted out... |
@ljlamarche you guys and you macs ;) I'm guessing this is some strange behaviour with Docker Desktop? It doesn't explain how @pmreyes2 was getting it to hang on his ubuntu server though... I'm heading in soon. |
Ok, got it. The |
The following doesn't hang resen:
So, in this case resen is not handeling the quit from jupyter, only the stopping of the bucket. |
Recap of private discussions that led to solution:
|
@ljlamarche @pmreyes2 alright, the hanging bug is fixed now. To test, you need to start_jupyter, and then in the container, modify the ~/envs/py36/lib/python3.6/site-packages/notebook/notebookapp.py by adding a Then you can start and stop the jupyter server as much as you want. It will not hang again. |
The hanging bug is fixed now and tested on my mac and on the linux server. @asreimer also tested on a windows machine. Closing the PR... |
This isn't finalized yet, I'm mostly starting this PR so we're all up to date on progress. I added several "helper" functions to validate input. Right now they're all just methods of the ResenCmd class. We discussed pulling them all into separate files, correct? Does that still seam reasonable?
The user interface seems to function at least. Give it a try and feel free to correct things!