Skip to content

Latest commit

 

History

History
60 lines (53 loc) · 3.35 KB

20220217-minutes.md

File metadata and controls

60 lines (53 loc) · 3.35 KB
Raw

Imaging Working Group Minutes

Thursday, 2022/02/17

10:00 am ET

Attendees:

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)

Minutes

  • 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?
  • 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