Open ThomasThelen opened 2 years ago
Thanks @ThomasThelen. Related to https://github.com/DataONEorg/slinky/issues/29.
Might contain some relevant virtual host config info: http://docs.openlinksw.com/virtuoso/qsvirtdir/
We talked about this last week and I said I'd have a look. Now that I have, I remember we talked about this quite a while ago and I think we decided we didn't want to expose the conductor externally anyway so I think the above statement:
We nee to configure the Slinky ingress to route traffic from *.dataone.org/slinky to Virtuoso.
Is no longer true. To access Virtuoso's conductor interface, I think we'd rather kubectl port-forward $POD $PORT_MAP
. And if we were to mount Virtuoso at a path, the latter probably would not work. Does that all make sense and match others' memory?
All that said, @ThomasThelen where does the current Slinky Ingress definition live?
I think things have changed a little since first creating this issue.
api.test.dataone.org/slinky -> Serves the webapp api.test.dataone.org/slinky/sparql -> Serves the virtuoso SPARQL endpoint Plus the ability to privately access the conductor (to do things like manage protected access to the endpoint)
Here's the ingress that I was previously working off of/trying to get to work. https://github.com/DataONEorg/slinky/blob/ingress_test/deploy/service/slinky-ingress.yaml
Ah, okay. Right.
I think the best thing would be for the webapp to own /slinky and everything under it. That would include the API we'll eventually build, proxying access to the SPARQL endpoint, etc. Does that seem reasonable? Putting a layer in front of Virtuoso makes it that much easier to swap Virtuoso out for another triplestore that still handles SPARQL but might use another URL pattern.
That sounds good to me. I imagine starlette should support this kind of functionality; one unknown to me is how accessing the triplestore interface behind the proxy, whether it's Virtuoso, GraphDB, etc...
I added another route to the webapp in https://github.com/DataONEorg/slinky/commit/9ec686b2f9507cf422fb831302a783db9b046690 that proxies incoming requests from /sparql to Virtuoso's SPARQL interface. It's totally hard-coded but I've left in TODOs where the rest of the implementation would go. Let me know if you wanna touch base on this @ThomasThelen.
FYI it's no longer hard-coded so it should forward your query and return its result.
We nee to configure the Slinky ingress to route traffic from *.dataone.org/slinky to Virtuoso.
One problem that I've come across is that the links in Virtuoso Conductor are relative to .dataone.org/, not .dataone.org/slinky. This results in a bunch of broken links and buttons. This can be seen on the test deployment.
Regardless of the broken links, the sparql endpoint works fine,
@amoeba suggested that an alternative is hosting the service at slinky.api.test.dataone.org.