|
| 1 | +--- |
| 2 | +title: ICAT Collaboration Meeting - 30th January 2025 |
| 3 | +date: 2025-01-30 |
| 4 | +chair: Rolf |
| 5 | +scribe: Louise |
| 6 | +--- |
| 7 | + |
| 8 | +## Attendance |
| 9 | + |
| 10 | +Attendees: |
| 11 | + |
| 12 | +- Rolf Krahl |
| 13 | +- Louise Davies |
| 14 | +- Marjolaine Bodin |
| 15 | +- Kevin Phipps |
| 16 | +- Malik Almohammad |
| 17 | +- Patrick Austin |
| 18 | +- Santhosh Anandarama |
| 19 | +- Viktor Bozhinov |
| 20 | +- Chris Prosser |
| 21 | +- Andy Gotz |
| 22 | +- Allan Pinto |
| 23 | + |
| 24 | +## Agenda |
| 25 | + |
| 26 | +## Site Updates |
| 27 | + |
| 28 | +### SESAME |
| 29 | + |
| 30 | +Portal running. Looking forward to add features to the Portal. |
| 31 | + |
| 32 | +### HZB |
| 33 | + |
| 34 | +Not much to report. Working on setting up central online storage - set up ingest workflows. |
| 35 | + |
| 36 | +### ESRF |
| 37 | + |
| 38 | +Still working with MX people to integrate ispyb into dataportal. Also merging in sample tracking to dataportal as well. Aiming for March to have both in. |
| 39 | + |
| 40 | +Users can reserve a DOI - and mint when data is published so leave data opening to last moment. |
| 41 | +OSCARS project called SHARE - database, similar to Paleo database & Human Organ Atlas, dedicated to Cultural Heritage |
| 42 | + |
| 43 | +### ISIS |
| 44 | + |
| 45 | +Adding new instruments. Certifcate updates. Updating the user office authenticator - migration from SOAP to REST - went into production last week. |
| 46 | + |
| 47 | +Currently working on migrating backup server from CentOS 7 to Rocky 9. |
| 48 | + |
| 49 | +### DLS |
| 50 | + |
| 51 | +New version of icat ingest client in place just before xmas. Kevin & DLS working on replacement for SQL jobs that propogate e.g. users, experiment info into ICAT - icat.sync. Python-based - using ICAT API rather than direct DB access. Went into production earlier this week. |
| 52 | + |
| 53 | +Up & coming - testing new version of DGW & ICAT 6.1 & new search (icat.lucene v3). |
| 54 | + |
| 55 | +Issue with tape library - tickets raised with vendor. |
| 56 | + |
| 57 | +### Sirius |
| 58 | + |
| 59 | +ICAT in production mode. passed security screening, ready to expose to external users. Right now, data is not open to external users but will in coming months. |
| 60 | + |
| 61 | +Working on extracting data from beamlines. Constructing pipeline to extract data from beamlines automatically to ICAT. |
| 62 | + |
| 63 | +We're ICAT now! :tada: |
| 64 | + |
| 65 | +## Component Updates |
| 66 | + |
| 67 | +### icat.server & icat.lucene |
| 68 | + |
| 69 | +Changes: started 3 years ago??? Been ready for a while. Main motivation: bring back datafile search (previously limited to 2B files due to max int size). Also added some new features, e.g. expanded fields able to search, sorting search results, faceted search. |
| 70 | + |
| 71 | +New major version of icat.lucene - requires re-indexing. Minor version of icat.server as icat.lucene is an optional component. icat.server - oppurtunity to not run icat.lucene & instead run Open/Elasticsearch directly. Should work with both as they had a similar interface when the search was done. Alan is working on some further work on the search to make it more compatible with Quarkus. |
| 72 | + |
| 73 | +icat.lucene now actually provides you with actual data, rather than just list of IDs (and you'd have to go back to ICAT to get the data from those IDs). Some more info being stored in the index, e.g. user info. Still checks via icat.server rules, but can do "rough" authz by doing searches like "show me results where I'm an investigationuser" which requires less work on icat.server authz. Also on authz, we batch authz checks rather than going 1 by 1 per result. Also added some timeouts for long running searches. |
| 74 | + |
| 75 | +Rolf: 2 Qs - on replacing with ElasticSearch - limitation of icat.lucene was you couldn't cluster - is that still the same? |
| 76 | +Patrick: still the same for icat.lucene. We've implemented a crude implemation of sharding to get around 2B index limit. Running against ElasticSearch you can use a cluster - limitations are that it might not load balance "properly", only sends requests to one server but that server can push requests on. Focus went away from ElasticSearch as DLS wanted to keep icat.lucene |
| 77 | + |
| 78 | +Rolf: would be nice to have comparison between icat.lucene and ElasticSearch. might be interesting to have an overview of pros & cons of each method. |
| 79 | +Patrick: supposed to have the same functionality - performance would likely be the main diff. Would be an interesting comparison. |
| 80 | + |
| 81 | +### ICAT stack containerisation/Quarkus |
| 82 | + |
| 83 | +Alan is still working on this. Main aim is to get it running on Quarkus so it can run in k8s - main issues are around threading. |
| 84 | + |
| 85 | +It has been brought up whether we can support both Payara & Quarkus with the same code - it might be leaning towards no but Alan isn't here to comment on that. |
| 86 | + |
| 87 | +Context for this is new facility in STFC coming online pushing us towards containerisation. |
| 88 | + |
| 89 | +Rolf: why need to move from Payara to run in containers? |
| 90 | +Kevin: Quarkus is aimed towards containers first. e.g. start up for Quarkus is magnitudes faster than Payara. |
| 91 | + |
| 92 | +### ids.server & python-icat |
| 93 | + |
| 94 | +No activity |
| 95 | + |
| 96 | +Andy: had a user ask about downloading .tar from IDS? |
| 97 | +Rolf: it's hard coded in IDS that it creates ZIP so would require a code change. Still have the issue that the codebase has lots of technical debt that needs refactoring - this would allow for easier developments of new features like this. |
| 98 | +Could easily change the current code, but the more you develop in the current code the more complicated the code gets. |
| 99 | +Andy: .tar is better if it gets corrupted |
| 100 | +Rolf: yeah, in back of mind have ideas of delivering more sensible return data. E.g. metadata in the returned data. But more complex, requires querying ICAT etc. In the future we might consider e.g. deliver an RO-Crate. |
| 101 | +Andy: yeah e.g. we don't currently deliver the licence either |
| 102 | +Rolf: yeah, thinking in the future including metadata would be nice |
| 103 | +Andy: also with ZIP file you lose original datafile datetimes for create and mod times. |
| 104 | +Rolf: might not be a ZIP limitation, might be IDS or storage limitation. Theoretically the metadata is in ICAT, so could query ICAT and use that. |
| 105 | + |
| 106 | +Rolf: can just open an issue - even if not to solve immediately just to keep track for the future. |
| 107 | + |
| 108 | +Kevin: did you have someone working on refactoring the IDS? |
| 109 | +Rolf: yes, but sadly that project has stalled. Difficult as more urgent things are needed at HZB right now, e.g. icat.server schema changes. |
| 110 | + |
| 111 | +## AOB |
| 112 | + |
| 113 | +### ESRF news |
| 114 | + |
| 115 | +ESRF has been added as a trusted data repository for europe. Kicks off next week. Part of [Fidelis](https://www.fidelis-project.eu) project. |
| 116 | + |
| 117 | +Also published paper on DRAC in synchrotron radiation news: https://www.tandfonline.com/doi/full/10.1080/08940886.2024.2432816 |
| 118 | + |
| 119 | +DOI landing pages - not compliant with google datasets. |
| 120 | +Rolf: HZB also needs to work on this as well |
| 121 | + |
| 122 | +Presenting next week on the PaN EOSC node. 11 catalogues brought online as part of EOSC federation. |
| 123 | +Rolf: HZB not mature enough for that yet we think |
| 124 | + |
| 125 | +DataPortal: exploring accessing multiple ICATs. That was in TopCAT though I think? |
| 126 | +Louise: Yes, but was not used! |
| 127 | +Kevin: Relies on having the same metadata |
| 128 | +Andy: Yes! Of course, would work for ESRF & ALBA as they're both ingesting the same data for MX (due to sharing ispyb specification). |
| 129 | +Andy: how did it work in TopCAT? |
| 130 | +Louise: selected the facility first, just basically two "TopCATs" sharing the same URL domain. |
| 131 | +Andy: MX has been wanting this for decades. |
| 132 | + |
| 133 | +Rolf: PaNOSC search api and PAN data portal was supposed to be this no? search api in bad state, but should probably work more on the search api. Not equivalent to Andy's usecase as it's more specialised, but search api could help generalised. |
| 134 | + |
| 135 | +Andy: Hiring someone in OSCARS to work on search-api. Plus the AI search project which likely wouldn't use the search api. |
| 136 | + |
| 137 | +Rolf: useful to work on multiple tracks at same time: specilised MX usecase, and also general case search-api. (search API is not currently useful). |
| 138 | +Andy: search api does work! just not useful |
| 139 | +Louise: actually the free text search doesn't even work for ISIS as it has too much open data. (Andy - we might work on that with the guy funded by OSCARS) |
| 140 | +Rolf/Andy: need more work on the data model. |
| 141 | +Andy: need to move on. Get experience for other community. [GoTriple](https://www.gotriple.eu/) in social sciences. |
| 142 | +Rolf: keep us posted! |
| 143 | + |
| 144 | +### Database exceptions |
| 145 | + |
| 146 | +Kevin: |
| 147 | +Database exceptions, root cause of the stack trace is connection closed in batches. Not often but everyday, 5-10 at a time until the next time in like 8hrs-a day. Bug in Payara? Bug in glassfish? Looked online & tried to be fixed multiple times but the same bug reoccurs. |
| 148 | + |
| 149 | +Preprod server only had one instance in like a year, but that's not used very much |
| 150 | + |
| 151 | +Marjolaine: yes we have it on production server on Payara 5. |
| 152 | + |
| 153 | +Issue seems to be stale connections. We have a check to see if a connection is live before using. If it's found stale it's supposed to be killed but it's not - it's returned from the pool. Then later something will pick up the stale connections. |
| 154 | + |
| 155 | +Patrick: if we use to Quarkus then we won't have that problem! |
| 156 | + |
| 157 | +Andy: related to when things get slow & we have to restart everything to fix it? |
| 158 | + |
| 159 | +Marjolaine: not sure, one time we had a lot of connections and there were too many and it caused an issue. |
| 160 | + |
| 161 | +Andy: one time last year load was so high on the server it had to be killed manually. We weren't sure what triggered it though. |
| 162 | + |
| 163 | +Rolf: an argument for clustering/k8s env as you could get higher availability |
| 164 | + |
| 165 | +### Digital Curation Conference Workshop |
| 166 | + |
| 167 | +https://dcc.ac.uk/events/idcc25/workshop-programme |
| 168 | + |
| 169 | +Andy: is anyone going? it's online. Just before [Digital Curation Conference](https://www.dcc.ac.uk/events/idcc) & [FAIRFest](https://fair-impact.eu/events/fair-impact-events/fairfest-celebrating-advancements-fair-solutions-eosc). |
| 170 | + |
| 171 | +Kevin: In the Hague? Antony our group leader is going to FAIRFest |
0 commit comments