Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dan Lester
    @danlester
    Do you get to see your dashboards eventually, or never?
    If never, let's work out if it's a dashboard issue or the same for regular JupyterHub singleuser servers. To do that, please try starting a new named server from the /hub/home page - type a name then click 'Add New Server'.
    Does that launch a new Jupyter instance? (And does it appear straight away, or 404 first...?)
    Sid Feygin
    @sfwatergit
    JupyterHub.png

    Hi Dan. Thanks for your response! I've decided to simplify things a bit and go back to a the ideonate default user image just to make sure I can get everything working ok (ideonate/containds-allr-datascience:0.3.0).

    Currently getting above

    (sorry... for weird ordering of those last msgs... thought gitter works like slack w/r/t pasting images)
    config is as follows
    vim_config_yaml.png
    Sid Feygin
    @sfwatergit
    and server doesn't start... this is a bit new now... probably a bit of misconfiguration on the EKS side
    Sid Feygin
    @sfwatergit
    JupyterHub.png
    ^ Similar sort of error when I tore everything down and rebuilt from scratch
    Sid Feygin
    @sfwatergit
    Error_report_from_ContainDS_Dashboards.png
    Removing the storage clause fixed this (although it seems dynamic storage would be useful in my case). However, something's still not right:
    Sid Feygin
    @sfwatergit
    upon sshing into the node instance and inspecting the container w/ the dashboard, I'm finding that the volume with the dashboard notebook was not attached to the container
    Sid Feygin
    @sfwatergit
    OK. So, after upgrading to cdashboards 0.9.3 (hub and singleuser) and adding dynamic storage back in, I can view my own dashboard, but as another user, I cannot view dashboards shared with me
    JupyterHub.png
    Sid Feygin
    @sfwatergit
    removing https seems to fix this, but that's not really an option for us
    Dan Lester
    @danlester
    @sfwatergit Thank for talking through all of this. It's great to hear you've (mostly) got everything working.
    This last hurdle ('Auth form must be sent from auth page') is something that came up recently for someone else. Not on k8s, but behind a reverse proxy that was terminating SSL. The issue is here: https://github.com/ideonate/cdsdashboards/issues/22#issuecomment-669090980
    In that case we are talking about nginx as the reverse proxy - for you it is just AWS load balancer, but it's likely the problem is the same.
    It is a bug/feature in either JupyterHub's OAuth code or in the Configurable HTTP Proxy component, depending on how you look at it.
    Unfortunately, the workaround suggested in the GitHub issue above won't work for you because in Zero2JH there is no easy way to specify a bespoke ConfigurableHTTPProxy.command setting to the ['configurable-http-proxy', '--no-x-forward'] which we need, as noted recently here: jupyterhub/zero-to-jupyterhub-k8s#1302
    Dan Lester
    @danlester
    Fixing the z2jh issue 1302 would be ideal in the short term. Using an alternative proxy (Traefik instead of the standard Configurable Http Proxy is supposed to be supported soon) might make this go away: jupyterhub/zero-to-jupyterhub-k8s#1162. Or trying a different https method could work - e.g. getting z2jh to do the https termination.
    But all of these have too many moving parts - I will look at building a workaround into the jupyterhub code used by ContainDS Dashboards. I am away this week but should be able to take a look at the start of next. In the meantime, I'm hoping you can continue evaluation with https off or moved to z2jh (if that solves the problem).
    Dan Lester
    @danlester
    I have registered this as a new issue on GitHub so we can track it there: ideonate/cdsdashboards#26
    Sid Feygin
    @sfwatergit

    Thanks Dan! I saw that GitHub post and was also puzzled as to how to achieve the same effect on AWS. Thanks for looking into this.

    I will proceed with HTTPS in the meantime. Eventually, the goal is to embed ContainDS into our web portal; permitting our data scientists to develop dashboards for internal and external consumption.

    Trying things out again, I seem to still have this issue with unbound PersistentVolumeClaims after replacing the suggested Dynamic Storage configuration settings (necessary for this to work, apparently):

        type: dynamic
        capacity: 10Gi
        dynamic:
          pvcNameTemplate: claim-{username}
          volumeNameTemplate: volume-{username}
          storageAccessModes: [ReadWriteMany]
    JupyterHub.png
    which eventually times out
    Sid Feygin
    @sfwatergit
    Also, getting an error with the default rshinydemo
    An_error_has_occurred.png
    although I've followed the directions as indicated
    Sid Feygin
    @sfwatergit
    Note I resolved the issue w/ pvc above by manually deleting the unbound pvc via kubectl. I will play around w/ EFS to see if it works better.
    Sid Feygin
    @sfwatergit
    EFS fixes issue w/ rshinydemo... perhaps instructions regarding storage classes were a bit unclear to me.
    Dan Lester
    @danlester
    @sfwatergit Sorry not to see this earlier - will take a look
    Which docker image are you using, and did you checkout the rshinydemo files from the git repo, or some other method? If you can show a screenshot of the tree that would be great.
    Sid Feygin
    @sfwatergit
    I would need to change the pv type back to dynamic to recreate, which I'm a bit loathe to do at the moment
    Sid Feygin
    @sfwatergit
    @danlester have been seeing some issues when trying to enable jupyterlab extensions. Please see following screenshot
    JupyterLab.png
    Dan Lester
    @danlester
    No problem re PV type.
    1 reply
    For JupyterLab extension, this has been renamed on final publish to NPM. Please try:
    jupyter labextension install @ideonate/jupyter-containds
    Or you can search within the extension manager in JupyterLab. I'll update the docs.
    Axel Larsson
    @AxelTLarsson
    Hey! I am testing out containDS on our company hub, it's very promising! I've had some minor issues, but solved them all so far. One thing that I'd like to do is to restrict non-technical users so that they can only launch already created voila dashboards, or at the very least remove their ability to launch a "normal server". I was playing around with DockerSpawner.allowed_images/image_whitelist, however, since it's the same image for both the normal server and the dashboard servers, just different commands, it won't do. Do you have any suggestions for how to proceed?
    Dan Lester
    @danlester
    @AxelTLarsson thanks for your feedback! Yes, I think this is a good suggestion. The main question is how to convenient assign 'non-technical' versus 'technical' status.
    Easiest (to start at least) would be an allow/block list to name dashboard creators
    Better would be to add to JupyterHub Groups - but there is no UI for that at the moment so I would want to add one myself really
    And then how to reshape the JupyterHub UI for these non-technical users so that, for example, ideally they don't see a 'My Server' or 'New Dashboard' button at all, and only get to see the list of dashboards.
    Some of this functionality would sit in JupyterHub itself ideally, but doesn't really make sense to the core JupyterHub project...
    Anyway, this is something I want to work on. All ideas and feedback welcome!
    I have created an issue to track ideonate/cdsdashboards#37