Greetings – Implementing a single endpoint was fantastically straightforward. Now that I’m feeling more ambitious, I’m struggling a little. There are two additional endpoints that I’d like to implement. One is strictly local (just another endpoint directed at a specific local server). The other is our subscription endpoint to the OSC Research Archive Storage. I’ve tried a few configurations based on the release notes, but the interface with the globus button does not show any additional endpoints. Clicking the Globus button signs in to the first endpoint listed in ondemand.yml.
That’s the general report. My question might best be brought to an office hour. But perhaps the above is sufficient to start discussion about:
implementing multiple local endpoints
how to configure also the OSC Research Archive endpoint
I’m a little confused because our configuration uses multiple endpoints and the globus_endpoints property is an array. Would you mind sharing your configuration?
Using the ‘Etc.getpwnam…’ remains a speculative venture on my part. On the production system, I’m going to default to just our primary Globus endpoint collection, which is listed first, and I’ll revert the path and endpoint_path to “/” until learning how to customize/implement for multiple endpoints.
I’m hoping to make it to office hours tomorrow to perhaps see a demo of how multiple endpoints present to the end-user.
Emily: We just had a bit of in internal discussion around this and think it might be more a Globus issue than an OOD thing. I’ll call their attention to this thread.
You have to remember what this feature does - it maps the local directory to the globus endpoint.
So something like this is trying to map the users $HOME (the Etc business setting the path) to that endpoint. Though the endpoint_path is likely off. Clicking that link may redirect to the globus directory $HOME/home, instead of what you want just $HOME.
This config should probably work for you mapping the users’ HOME directory to the globus endpoint.
So in the case of two endpoints, let’s neglect the path details for the moment, what should the interface share? So far, I’ve only seen the Globus integration share the first listed endpoint. Is this what Alan refers to as a Globus problem?
This will result in a successful launch of Globus, with the endpoint listed first active in the interface, but no obvious indication of the 2nd endpoint. So in part, I’m wondering just how should the “availability” of the 2nd endpoint be visible in the Globus session?
The other question I had was about the endpoint for the OSC Research Archive Storage. Can you share specifics about managing that path/endpoint-path info? I have the endpoint identifier (which will be unique to CWRU), but I don’t understand the remote filesystem. I guessed based on info from my globus console to use “/fs/ess”, but am guessing know that there must be a host specified.
This config indicates you’re entire filesystem is a globus endpoint, all the way up to the tippy top root /. I’m guessing the second /scratch never shows up because the first is logically above it. I mean if / is the mountpoint, then everything below it is a part of it - even /scratch.
I’m just learning about this so I don’t know for sure - but again, this feature maps local filesystem to the globus endpoint. Is there any local directory location at CWRU that’s a part of this globus endpoint? If not, then it doesn’t really make sense here because in the file browser, you’re navigating the local filesystem. If there is, then it should behave just like any other globus endpoint.
Hi Emily. The purpose of the Globus button is to take the Open OnDemand user from a view of a folder in Open OnDemand to a view of the same folder in Globus. We want to enable the person to transfer files into or out of that folder using Globus. The button in Open OnDemand is never intended to open two locations in Globus. The intent is to open the same folder in Globus that you were looking at in Open OnDemand so you can use Globus to transfer files in/out instead of using Open OnDemand’s upload/download buttons. The upload/download buttons can only transfer files to/from the user’s computer. Globus can transfer between the Open OnDemand cluster and any other Globus-connected system (e.g., a different campus cluster, a system at another institution, an ACCESS or DOE supercomputer, etc.).
Once you’ve clicked the Globus button and are taken to Globus, you can open a second panel by clicking the columns indicator in the upper-right of the Globus interface. (See the figure below.) In that second panel, you can pick the location where you want to transfer your dat to or from.
We asume that the Open OnDemand user needs to transfer data to or from a second location, but only the user knows where that second location is! We don’t presume to know both the source and the destination.
Yeah, we don’t consider elements of the filesystem to be different endpoints. It’s the servers allowing access that we consider endpoints. Perhaps our view is out-of-date, from the time when an endpoint was identified as server#institution. But yes, our two endpoints just make the full filesystem accessible. One endpoint uses servers in our SciDMZ, while the other endpoint is a server in our data center, but “within” the campus network. So the endpoint distinction is meaningful, and worth preserving.
My understanding of the archive endpoint at OSC was that it is truly hosted at OSC, associated with the large-scale tape storage system. Here’s the first few lines:
Display Name
CWRU Research Archive
Entity Type
Guest Collection (GCS)
Mapped Collection OSC /fs/ess
Endpoint OSC GCSv5
Hope this helps clarify the endpoint details.
Cheers
~ Em
ps good chance i’ll be able to attend the start of office hours.
