search

DataONEorg / slinky

Slinky, the DataONE Graph Store
Apache License 2.0
4 stars 4 forks source link

Configure the Slinky Ingress #60

Open ThomasThelen opened 2 years ago

ThomasThelen commented 2 years ago

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,

curl -G https://api.test.dataone.org/slinky/sparql --data-urlencode query='SELECT DISTINCT * WHERE { ?s ?p ?o} LIMIT 1000'

@amoeba suggested that an alternative is hosting the service at slinky.api.test.dataone.org.

amoeba commented 2 years ago

Thanks @ThomasThelen. Related to https://github.com/DataONEorg/slinky/issues/29.

mbjones commented 2 years ago

Might contain some relevant virtual host config info: http://docs.openlinksw.com/virtuoso/qsvirtdir/

amoeba commented 2 years ago

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?

ThomasThelen commented 2 years ago

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

amoeba commented 2 years ago

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.

ThomasThelen commented 2 years ago

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...

amoeba commented 2 years ago

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.

amoeba commented 2 years ago

FYI it's no longer hard-coded so it should forward your query and return its result.