February 3, 2016

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

• Time: 1:00pm Eastern Daylight Time US (UTC-4)
• Dial-in Number: (641) 715-3570
  • Participant Code: 304589#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  • Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #islandora on irc.freenode.net

Attendees

• Melissa Anez
• Nigel Banks
• Jared Whiklo 🌟
• Danny Lamb
• Mark Cooper
• Ben Rosner

Agenda

1. Sprint debrief
2. Project Plan
3. Next Sprint
4. ... (feel free to add agenda items)

Minutes

1. Sprint debrief

2. Ansible

   Ansible was working, but making it work with Docker caused it no longer works with AWS. So Nigel is working to fix it for the various providers. Currently it is Ansible script to do provisioning and has some other scripts to cover other issues.

   The normal way is to have a bunch of layers and each layer is a Git repository. The benefit is to have Docker Hub tie in and have it build a new image when someone commits to each repository. There are ways around but it might be worthwhile to factor things out now.

   Danny: The original reason why it is all on one spot was to one issue one PR, instead of multiple repos and the optional parts. If we split it out (perhaps Java, PHP, Drupal), we could have one GitHub repo that uses the others as sub-modules. Then can we submit a single PR to the parent module and not have to commit to each?

   Nigel has been investigating Git sub-modules and sub-trees. If you are simply a consumer it is okay, but for developers there is a little more burden. But Nigel thinks it might be worth it. But there is also some catches, you have to keep the sub-trees clearly separated or you can't maintain external repositories on each of those sub-trees. Nigel feels that sub-modules are a little more work, but we are less likely to mess it up later.

   Ben says that is how they (Barnard) use it to deploy Islandora. Danny: If we want to get on Drupal.org we will need to split it up at some point. Ben's repo allows him to do a git submodule init && git submodule update when spinning up a new vagrant and it pulls the head of each defined submodules. Ben clarified that he runs a bash script to iterate through the submodule folders to fetch head on each.

   Nigel feels like we are missing out on the additional Docker tooling that we could use with split up repositories. Which would provide us with essentially free continuous integration.

   Could we spin up an instance without vagrant/VirtualBox, just using Docker images running on the actual machine? That is possible yes.

   Nigel: Docker gives you a nice caching layer, but Ansible gives smaller images because they are in a single commit. So we could end up with a set of Ansible scripts and a set of Docker files, and the deployment could be either/of/both.

3. Drupal Triplestore Indexer

The actual data triples are available to present to the outside world for external linked data. Does have some issues like how do we make all this work and still use LDP, especially as Fedora likes to be the master. Where we are treating Drupal as the master, but also letting Fedora deal with its own date on a Fedora level. Perhaps a reasoner, string conversion, or something thing along those lines to deal with it.

Now that the triplestore is meant to be outside the firewall, so our services are not required to use the triplestore, we can use a different (JSON-LD?) document store.

Right now the Drupal triplestore indexer all goes to the same location as Fedora triples. But can be pointed anywhere. Very straightforward implementation.

Should we look at separating Fedora data from Drupal data, perhaps namespaces in Blazegraph or named graphs? This seems like a good idea but with limited expertise on how to. Good point for exploration.

**Danny** knows of some people are interested in just the services of CLAW to use for creating/updating PCDM objects, but without the Drupal front-end.

2. Project Plan

   There are concerns that our sprints and general direction could use some more forethought to allocate our limited resources correctly.

   Danny: We want to ensure we sandbox each services from one and other so changes are easier.

   Nigel: We are new to this and don't want to make a huge decision and lock us into something we may not like, but at some point we need to make some of those decisions.

   Danny: We have been talking over "what Islandora is" for a year and we are still talking about it. Danny has been pushed to be the direction of the project, but he would prefer that this is a group decision.

   Melissa: It is easier to work off a draft then group-write a new one.

   Danny will write a first draft (for the third time), but the group must tear it apart and ensure it describes what we want.

   I say again Danny will write the services document and then the group will look at it and pick it apart.

   Then at the end, we need to break it down into manageable chunks. The difficulty is that things are related so one small change can have a ripple effect on other parts of the project. But this results in an easier entry point for new people. The asynchronous problem is of particular interest, but is also the scariest problem.