Thursday, 2022/02/17
10:00 am ET
Terrell Russell, Alan King, Kory Draughn, Justin James, David Fellinger, Hiroya Itoga (RIKEN), Josh Moore (Dundee / OMERO), Michelle Itano (UNC Microscopy), Caterina Strambio-De-Castillia (UMass Medical School), Ken Ho (Crick, UK), Ingrid Barcena (KU Leuven), Paul Borgermans (KU Leuven), Tessa-Jonne Ropp (UNC Microscopy), Jef Scheepers (KU Leuven), Mike Conway (NIEHS)
- Terrell confirmed access to UNC/Odum OMERO (sand-box) server
- Need to test user scripts and firewall to NeuroZone
- Possible alternate mapping into iRODS/NFSRODS
- To get around the single author/owner on the OMERO side
- Possibly have to trust the OMERO claim (not ideal)
- Currently UNC using LDAP(UNC onyen) to get into OMERO
- Groups in OMERO are not linked/synced from LDAP at UNC
- But they could, given the correct permissions/configuration
- Could OMERO know/pass that along to iRODS?
- Groups in OMERO are not linked/synced from LDAP at UNC
- OMERO has 'symlink'-in-place option when loading data
- Need to provide docker-compose project that sets up a couple of these services
- To test the permissions/sharing discussion above
- Michelle scenario
- Data acquired, dropped into a server, then 'ingested' into iRODS
- Tagged as 'microscopy', and perhaps 'ready for omero'
- OMERO can then see it
- iRODS would 'take over' the in-place registration from OMERO
- Consider OMERO has no write permissions, read-only via NFSRODS
- Josh
- Files loaded in OMERO, then iRODS is informed...
- Then iRODS/script steals the files out from under OMERO (aka symlinks)
- Terrell
- What if ... there is no file sync... we just get files upon demand (via Python/Java)
- But OMERO doesn't have a VFS (virtual filesystem layer/abstraction)
- Maybe NFSRODS is the wrong level - too low level
- What if single OMERO user - no multiuser
- No existing visibility into who did what on the iRODS side
- But could be mitigated with extensive/consistent/thorough metadata
- Depends on the questions you'd like to answer later / reporting
- There could be a contract/agreement/understanding that OMERO assumes ownership based on the iRODS namespace information
- Mike
- This sounds more like an OMERO ‘synch’ agent that needs to query OMERO as ingest/synch happens to derive metadata values? Am I misreading this?
- Either from LDAP, or OMERO, or iRODS
- Something has to be 'in charge', the source of truth
- A sync agent that sits between OMERO and iRODS, speaks to both
- Can move files, query things, make assertions, annotate in either system
- Files in iRODS, tells NFSRODS, shows up for OMERO
- Files/annotation show up in OMERO, written as omero, but then agent can execute policy to name them well (and tell OMERO it moved), change ownership, etc., similar to Utrecht/Yoda use case
- This affords more policy driven by iRODS, communicated back to OMERO where appropriate (via events, or just more metadata?)
- A fine carrot for increased interest/use by additional users / use cases
- Provides confidence / bumpers for users as well
- No need for OMERO- or iRODS-specific code in either place
- Consolidates logic into single source of coordination
- Sync agent will need to be admin / admin in both directions
- Maybe just a docker application(!)
- Next Meeting:
- Mar 2022