Time/Place

This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• Audio/Video Conference Link: https://lyrasis.zoom.us/j/396037251
  
  • Meeting ID: 396 037 251
  • Find your local number: https://lyrasis.zoom.us/u/ad6Xb7q3ia

  • Join fedora-project.slack.com on the "tech" channel

  • Self-register at: http://slack.fcrepo.org/

Attendees 

1. Danny Bernstein 
2. David Wilcox 
3. Jared Whiklo 
4. Peter Winckles 
5. Daniel Lamb  
6. Ben Pennell
7. Calvin Xu 
8. Michael Ritter 
9. Demian Katz
10. Geoff Scholl
11. Steve Liu

Agenda

1. Announcements
   1. Camel Toolbox Sprint - first week in October.
2. Review of  Work in Progress (round robin)
   1. Camel Tool Box (CTB) Update 
      1. completed :
         1. fcrepo-indexing-triplestore
         2. on/off switches or services
         3. Mega-PR with instructions for testing solr and fuseki.
      2. PRs
         1. Ready to be merged: https://github.com/fcrepo-exts/fcrepo-camel/pull/163
         2.  New PR which depends  on the  above  PR: https://github.com/fcrepo-exts/fcrepo-camel-toolbox/pull/160
      3. TODO
         
         1. Dockerization / Compose 
         2. microservices still needing to be upgraded:
            1. fcrepo-audit-triplestore
            2. fcrepo-fixity
         3. Integration tests for the spring app
         4. Documentation
         5. Consolidate / Rationalize Property Names
3. Configurable HTTP Service for Camel Toolbox
4. Dangling PRs:
   1. docker multi architecture builds.
      1. https://github.com/fcrepo-exts/fcrepo-docker/pull/14
      2. https://github.com/fcrepo/fcrepo/pull/1923 
5. Releases
   1. fcrepo-upgrade-utils  - 6.1.0 - not done yet
6. Additional Priorities for Sept/October?
7. Your topic

Tickets

1. In Review

   Click here to expand...

   type	key	summary	assignee	reporter	priority	status	resolution	created	updated	due
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

2. Please squash a bug!

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

3. Tickets resolved this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

4. Tickets created this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Notes

1. Announcements
   1. Camel Toolbox Sprint - first week in October.
      1. Focus on reaching 1.0 release
      2. One-week sprint should be enough; things are already "mostly there."
2. Review of  Work in Progress
   1. Camel Tool Box (CTB) Update 
      1. Danny finished triplestore indexer this week, completing main goal of Camel Tool Box upgrade
      2. Also added on/off switches for reindexer, Solr and Triplestore (all off by default); Fedora service is always on by default and has no switch (assumed to be needed). ldpath service is also always on.
      3. Mega-PR of changes has been put up (https://github.com/fcrepo-exts/fcrepo-camel-toolbox/pull/160). Please look (even if just a section) and critique; Danny will extrapolate your comments to apply changes to all relevant files. There has been a focus on integration tests, since APIs and style/conventions have changed since the earlier version of Camel.
      4. You can also test the new PR using Docker configs (see notes in PR description for details)
      5. Major remaining TODOs:
         1. porting fixity and audit-triplestore, which is just pulling logic out of OSGI and updating tests.
         2. Could use a smoke test for the spring app as well.
         3. Solr integration test would be nice
         4. Some property names are inconsistent; Danny kept them as-is for now during migration, but it would be good to revisit and make them more logically normalized. All properties have been documented on the README test.
      6. Demian asked about production deployment; Danny suggested that this involves having a separate ActiveMQ server that receives ActiveMQ messages emitted by Fedora and stores them in a durable internal queue, and then the Camel Toolbox runs from that queue to avoid dropping of messages. (You should also configure Fedora to use a queue instead of a topic, to ensure that messages are not lost if something goes down outside of Fedora).
         1. A diagram might be a good addition to the README as this matures further.
      7. Steve reported that his team is having some difficulty getting things working; messages may be getting lost somewhere. Danny mentioned having some difficulty getting Solr cores initially created for testing purposes (due to inconsistent documentation, etc.). General troubleshooting suggestions were shared; Steve will check whether messages can be sent to Solr from the command line using curl. If that doesn't reveal a solution, Danny will share Solr configuration with Steve via Slack to compare and determine whether the problem might be a schema inconsistency.
      8. Danny hopes that by the end of today, it will be possible to build the toolkit directly from pull request #160, which will make it easier for people to try out the latest version.
3. Configurable HTTP service for Camel Toolbox
   1. JIRA ticket: https://fedora-repository.atlassian.net/browse/FCREPO-3753
   2. Danny suggested that this is similar to the ldpath and solr use cases: taking a message, pulling some information, formatting it into a call. It would make sense to be able to define multiple instances of this service with different configurations, to allow it to be used for multiple purposes at once. Configuration would essentially consist of a template for specifying headers, a URI, and a body. It might be possible to use regex instead of ldpath for an even simpler approach. Possible limitation of current ldpath service: only supports one translator at a time.
   3. Jared suggested as a simple approach, creating a service that just posts a message to an external service as-is, letting that service manage the transformations, etc. This would be a simple "minimum viable product" though less flexible than the configurable approach described above.
   4. The MVP "just forward the message" service would probably require only one instance, unlike the hypothetical, more complex version.
   5. Demian suggested that some kind of filtering mechanism might be useful in combination with the proposed MVP so that only relevant messages are forwarded (e.g. only add/delete). This would just require us to decide on the most user-friendly way to configure such filters. Simple substring matching might be adequate.
   6. Proposed first approach: a single instance of the MVP idea, using the http component to forward messages in the body.
   7. Security was discussed: it was suggested that MVP should at least include basic auth.
   8. HTTP method should be POST to start with. Maybe other methods would be useful in future.
   9. For future growth, allow a JSON configuration file to be specified to describe multiple endpoints, etc., etc.

Actions

• Demian will add notes about HTTP service to JIRA ticket