Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
- Andrew Woods
- Nicolas Dickner
- Michel Heon
- Bruce E Herbert
- Sacha Jerabek
- Ralph O’Flinn
- William Welling
- Paul Albert
- Sarbajit Dutta
- Brian Lowe
- Huda Khan
- Sacha: UQAM had internal sprint with web developer to restyle VIVO.
- Sprint updates: testing Kafka with ORCID - UQAM and TIB
- Michel: retrieved all users from ORCID; persons batch-pushed into VIVO using Kafka.
- Conversion from ORCID JSON to VIVO RDF; sent to Kafka channel; pushed to VIVO.
- TIB worked on listening to VIVO changes and sending them to Kafka channel.
- Next step is putting this work on Github.
- Will continue to develop this method of injection in December/January.
- Bash scripts will be converted to Java code/services.
- Advantage of this approach is reusable design patterns / Kafka consumers.
- All messages on Kafka channel are in “VIVO” format using VIVO vocabularies.
- Kafka workflow and ReCiter?
- Paul: Our VIVO is read-only, so won’t be used to syndicate content out via something like Kafka.
- Andrew: Kafka producer and consumer architecture can include mediation steps before being consumed by VIVO.
- William: Could any triple changed in VIVO be immediately streamed out via Kafka? Or would it need to buffer and batch up changes?
- Michel: Kafka intended to be used in real-time streaming applications using large amounts of data.
- William: seems like an advantage over something like ActiveMQ.
- Kafka consumers/producers should be internal to VIVO; use consumer instead of SPARQL API.
- Ralph: next week should be a data ingest meeting with demo from TIB. Vote for date/time on data ingest Slack channel.
- Messaging architecture may reduce need for or desirability of intermediate relational data stores between raw data sources and VIVO.
- Sarbajit: API bugfix testing
- Works as long as maxPostSize is also correctly set.
- Site admin users unable to add new individuals
- Huda: has taken an initial look at things; will make some more time to stare at the code. Huda and Andrew had looked at the options and while there are opportunities for long-term refactoring, it is probably better to release a patch that works right away and then consider a better long-term strategy. Brian will also try to look more at the issue and add hints to the JIRA issue if they suggest themselves.
- Using Github issues instead of JIRA
- Michel: sprint planning?
- Ralph: Github has features that match most of what JIRA has.
- Michel: Github generally seems like a big list of issues, but hard to categorize.
- Andrew: there are different labels to apply to issues.
- Tooling on top of Github issues?
- William: There are various projects for more elaborate Kanban or other things on top of Github issues. Lot of work to make it happen: may not be something we want to take on at this time.
- William: Might be good to have trial run with Github issues before moving everything other.
- Andrew: have meeting with Tim Donahue of DSpace project. DSpace has already done a similar transition. Will ask for feedback/advice.