Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Sid Feygin
    @sfwatergit

    Hi! Thanks for developing this project. I'm currently evaluating it for use as an internal/external analytics framework for my company.

    I've followed the Z2JH setup (on AWS EKS) as well as the setup provided on your site. I've customized the Dockerfile used by the User nodes for our use case. So far, most features work as advertised except that we are getting 404s upon navigating to the dashboard servers. How should I go about debugging this issue?

    Dan Lester
    @danlester
    Hello! Thanks for getting in touch. I sometimes see 404 for a new dashboard on Kubernetes, but if I refresh after a few seconds it's all working. I think that's general JupyterHub issue (that I'd like to look into anyway!)
    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