Document flow improvements, expanded on Jupyter usage #120
Conversation
|
Hi @elsonrodriguez. Thanks for your PR. I'm waiting for a kubernetes or google member to verify that this patch is reasonable to test. If it is, they should reply with I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
| @@ -95,21 +100,53 @@ http://xx.yy.zz.ww:31942 | |||
|
|
|||
| For some cloud deployments, the LoadBalancer service may take up to five minutes display an external IP address. Re-executing `kubectl get svc` repeatedly will eventually show the external IP field populated. | |||
|
|
|||
| Once you have an external IP, you can proceed to visit that in your browser. The hub by default is configured to take any username/password combination. After entering the username and password, you can start a single-notebook server, | |||
| request any resources (memory/CPU/GPU), and then proceed to perform single node training. | |||
| Once you have an external IP, you can proceed to visit that in your browser. You should see a sign in prompt. | |||
There was a problem hiding this comment.
Do we need to change this? I don't think we should be opening an external IP by default. So I think we should tell people how to connect via kubectl until we have a recipe for connecting securely via https (#11).
There was a problem hiding this comment.
The security culture for k8s examples is pretty loose, however the documentation already mentions that by default this is totally insecure.
I do feel this is a continuation of a bad precedent.
A good solution would involve getting kube-cert-manager and external-dns configured, along with adding whitelists to the Service objects via ksonnet based on the user's IP, however I'm focusing on just getting things working for now.
I can switch everything to use port-forward if needed.
There was a problem hiding this comment.
If you don't mind, I'd prefer for us to use port-forward and not promote insecure methods; thanks
There was a problem hiding this comment.
Mind if I tackle the port-forward in another PR? It'll take me a bit to mess with ksonnet and put a toggle in there for loadbalancer vs port-forward (for those who want to use LB still)
There was a problem hiding this comment.
I think that's fine; since the code is already using LoadBalancer by default and this PR is just documenting current behavior.
|
|
||
| Paste the example into a new Python 3 Jupyter notebook and execute the code, this should result in a 0.9014 accuracy result against the test data. | ||
|
|
||
| Please note that when running on most cloud providers, the public IP address will be exposed to the internet and is an |
There was a problem hiding this comment.
As noted above can we change this and make the default deployment of JupyterHub use ClusterIP?
My hope is that various Cloud Providers will chime in and provide help making JupyterHub secure.
On GKE I think it makes sense to do this using IAP (#60).
One option to provide a Cloud Agnostic secure method for accessing JupyterHub would be to use JupyterHub's built in OAuth support. I think it has a GitHub authenticator. Should we open up an issue for that?
There was a problem hiding this comment.
Providing clean authentication is one of the goals of JupyterHub. There's a lot listed on https://github.com/jupyterhub/jupyterhub/wiki/Authenticators and more around the web.
|
Yeah, that inception client looks right! I'll give it a test within a day or two. |
|
LGTM. Please sync and I'll merge this. |
…int. Need to find a container that contains the inception_client to test.
elsonrodriguez
force-pushed
the
user_guide_pass2
branch
from
52f94d7
to
1861a16
Compare
|
Rebased. |
Signed-off-by: YujiOshima <yuji.oshima0x3fd@gmail.com>
Added josiemundi
Also added more info on the inception endpoint. Still need to provide an example with an inception client.