Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-22330

Error box when loading jupyter -int notebook about unable to detect TAP URL

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Gregory Dubois-Felsmann 4:49 PM
      So I think what is happening is that a) the initialization code for the TAP query screen is running even before it’s actually invoked (this is an issue of the way the JS application is structured that is way out of my current level of knowledge) and b) it’s seeing the URL of the JupyterLab session, perhaps, instead of the Portal — or it’s seeing the non-standard (instance)/firefly URL that Adam controls. If it’s the latter, though, I don’t know why it would be running the TAP initialization code, because that’s not in the application that Adam runs.
       
       
      4:50 PM
      All of which is to say, Adam is correct: if the base URL from which the application is trying to deduce the TAP URL were in the error message, there would be less speculation involved here.
       
      4:51 PM
      But still: something changed from Wednesday, and it certainly wasn’t something we did on our side.
       

      Christine Banek 4:51 PM
      well one thing that I think may have changed (or even probably changed) is now jupyter is probably pointing at a different of the many firefly urls
       
      4:52 PM
      I believe yesterday jupyter -int's firefly pointed at an internal firefly jupyter which was at -int.ncsa.illinois.edu/firefly, now it's pointing at /portal/app
       

      Gregory Dubois-Felsmann 4:52 PM
      OK, so I do see the message when Jupyter loads, and I agree, it must be part of the initialization of the application.
       

      Christine Banek 4:53 PM
      so we might have implicitly kind of changed what firefly version jupyter is talking to
       

      Gregory Dubois-Felsmann 4:53 PM
      Yes, I think you did.
       

      Christine Banek 4:53 PM
      but it does seem to work, we ran the firefly notebook and it worked
       

      Gregory Dubois-Felsmann 4:57 PM
      I think the only issue is that the LSST Portal application (which is what you are now running after what you changed - you used to be running “vanilla” Firefly) uses window.location.href in the TAP initialization code to introspect on where it’s running. Apparently when this runs inside JupyterLab it sees https://lsst-lsp-int.ncsa.illinois.edu/nb/user/gpdf/lab or something like that. It’s expecting to see (scheme)://(hostname)/(optional stuff)/portal/(anything) and then it works back from that to decide that the TAP service is at (scheme)://(hostname)/(optional stuff)/api/tap .
       
      4:58 PM
      So there’s no “portal” in the window-level property window.location.href when it runs under JupyterLab and this logic fails. (edited) 
       
      4:59 PM
      It doesn’t use just (hostname) because we wanted to be robust to possible LSP deployments with a pathname component in the instance, like some future https://www.lsst.org/lsp/api/tap / https://www.lsst.org/lsp/portal situation, or something analogous in the cloud.
       
      5:00 PM
      If we had just naively used the hostname alone, this would have accidentally been OK.
       

      Christine Banek 5:01 PM
      well it's not a big thing, it's just annoying because it comes up everytime someone logs in. but it seems like just some debt we've uncovered in getting to just one copy of the portal running
       
      5:01 PM
      because it sounds like this configuration should work, and is what we want, right?
      ----new messages
       

      Gregory Dubois-Felsmann 5:02 PM
      Yes, that’s right. What we really wanted is to get the URL of the Firefly server, though, not the URL of the JL session. I wonder if that’s available in a way that isn’t itself fragile in some other way.
       
      5:03 PM
      We have to autodetect the URL for TAP or there will be a credential mismatch - we can’t just hard-code -stable or something like that.
       
      5:04 PM
      We’ll have to think about this.

        Attachments

          Issue Links

            Activity

            Hide
            cbanek Christine Banek added a comment -

            "Could not auto-detect the location of the TAP service for this LSP instance." is the error message

            Show
            cbanek Christine Banek added a comment - "Could not auto-detect the location of the TAP service for this LSP instance." is the error message
            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            Fixed in suit:1.1.1 release.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - Fixed in suit:1.1.1 release.

              People

              Assignee:
              gpdf Gregory Dubois-Felsmann
              Reporter:
              cbanek Christine Banek
              Watchers:
              Adam Thornton, Christine Banek, Frossie Economou, Gregory Dubois-Felsmann
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.