Skip to end of metadata
Go to start of metadata


Call-in Information

Time: 11:00 am, Eastern Time (New York, GMT-05:00)

To join the online meeting:



(star)  Indicating note-taker

  1. Don Elsborg  
  2. Huda Khan (star)
  3. Ralph O'Flinn
  4. Andrew Woods 
  5. Steven McCauley
  6. Harry Thakkar


  1. Sprint update
    1. Demo of:  VIVO-1685 - Getting issue details... STATUS
  2. Given Fly-in design overview
    1. Where are the open questions?
    2. How can we move the effort forward (2019 sprints, Product Evolution, other)
  3. Search index: approaches for configuration and processes 

  4. Acceptance tests moved to vivo-community, thanks Jim Blake
    2. How to run it
  5. Status of In-Review tickets

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due

    1. Soft balls

      1. VIVO-1659 - Getting issue details... STATUS
        1. Low-hanging, documentation - Mike Conlon, can you give this one a review?
    2. Regular balls
      1. VIVO-1675 - Getting issue details... STATUS

        1. New
      2. VIVO-1670 - Getting issue details... STATUS

        1. Kitio Fofack ? Orcid and i18n

      3. VIVO-1656 - Getting issue details... STATUS
        1. Is this feature of broader interest?
      4. VIVO-1643 - Getting issue details... STATUS
        1. Andrew Woods to look into
      5. VIVO-1642 - Getting issue details... STATUS
        1. Mostly trivial, with conversation around Tomcat version support
      6. VIVO-1630 - Getting issue details... STATUS
        1. Kitio Fofack to review?
  6. Received

     Click here to expand...
     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due

    1. VIVO-1666 - Getting issue details... STATUS  

      1. (re-)Raises interest in reconsidering first-time, every-time, tdbconfig design

    2. VIVO-1665 - Getting issue details... STATUS  
      1. Should be low-hanging
    3. VIVO-1663 - Getting issue details... STATUS  

      1. Where does this stand? What is needed to add more person identifiers to VIVO?

    4. VIVO-1644 - Getting issue details... STATUS  
      1. Mike Conlon : thoughts on where this stands?
  7. Bugs (1.11)

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due


Draft notes in Google-Doc

Ralph was trying to demo a ReactJS UI with GraphQL for product evolution but ran into some technical difficulties and will be redoing that demo later.

Harry figured out compilation error in last 30 seconds.  Last four steps in instructions need to be updated. Don’t need to checkout sprint-search branches - those appear to be problematic.  

Andrew: issue with that is that if not checking out the sprint search branch, not dealing with externalized Solr but the internal Solr.

Ralph: Also Java 11 fixes, updated smoke tests in that branch.  What is breaking with the Docker process? Haven’t finished Docker piece yet.

Harry: Hadn’t realized that need those branches so will try with them.  Anything recently pushed?

Andrew: Not since November. Suspects that need to bring in latest into those branches

Ralph: Good to merge in main branch back into sprint branches.  Will work with Harry to figure this out.

Harry: Looks like a Java version error.  

Harry: screen sharing!

Docker-compose build

Downloading all the things - lots of downloading

Error seems to be finding JAVA 11 and expecting JAVA 9

“Cannot access UnsupportedEncodingException”

“Class file has wrong version 55.0” (corresponds to JAVA 11)

Andrew points out:

Harry and Ralph will reconvene after call to look at this issue.

Don may also try to help with this later.

  1. Sprint update


    2. Objectives:

      1. Branches for externalizing Solr and ElasticSearch

        1. Get those branches to a point where they can be merged into develop branch

        2. Ralph will be looking at this work this week

        3. Jim provided nested ElasticSearch population code right before retiring

        4. Laser focus goggles on for Ralph

        5. Don: Can we just get rid of the war file?

        6. Andrew: Interim state where not supporting external Solr but taking out internal piece

        7. Harry: build fails - but seems very close - some setting needs to be changed

      2. Building of VIVO Docker

        1. Achieved and still in review

        2. Hope to have a successful demo in the next week or so

        3. Don: Multi-stage VIVO? Others: Yes

          1. Build a war class and copies it over. Can we copy over file to locally so can deploy/ship to cloud?

          2. Andrew: Separate VIVO Docker page that assumes VIVO war file

          3. Don: Practicality?  Run one Docker, create WAR and copy locally.  Another Docker to create Tomcat container and copies WAR file from local volume and deploys that as a separate step

          4. Andrew: Possible.  If someone doesn’t want customizations and just wants to deploy, new Docker process could pull down WAR and then deploy

          5. Don: Current work great for MVP - but not 100% practical yet for the real world.  Tooling and scaffolding like Ansible builds - own war file/runtime properties.

          6. Harry: Like mention of Ansible. Why can’t we achieve same objective with Docker compose?

          7. Don: We can.  Docker using YAML anyway and Ansible is super set.  At our institution, have 3 tier build. Dealing with secret management and customizations.  Had used Ansible before. The Docker work gets us close to doing automated custom builds. Perhaps Docker compose could work but can also run compose with Ansible.

          8. Harry: Can’t comment on Ansible since haven’t used it.  Docker compose is orchestration so could use that for three/multi-tier application.  What we have now is a very basic Docker compose and could go deeper to avail ourselves of deeper features.  

            1. If distributing two parts, one creates war, and second uses war shared by Docker compose.  Idea that if someone wants to deploy they just use that single compose.

              1. VIVO is sitting in Maven as a war file ready to go or as an image.

            2. Consider this work as an initial step and then we can go further

        4. Don: Between having to maintain VIVO at institution with VIVO work that seems more “vanilla” deployment.  The closer these two come together, the more likely I can be involved.

          1. Even with institutions that are at older versions of VIVO, the easier we make it for them to upgrade, easier to bring them into the community effort.

          2. Andrew: community. +1

        5. Andrew: Doing fairly well with this objective. Have Docker compose files.  

      3. Solr Docker: done.  Solr image and our local usage of image uses Solr configuration expected by VIVO.  

      4. ElasticSearch: Not much in this area.  Probably easy to do once we actually do it. Have been looking at Solr and MariaDB first.

      5. MariaDB instead of MySQL: done

      6. Documentation: less so. In Duraspace wiki, copied 1.10 documentation into 1.11 space.

      7. Documentation: less so.

    3. Focusing on objective (i) currently.  Ideally, good to get this to point where we can share back with community.

    4. Don: project template geared towards multi-tier VIVO. Separate repo for Docker components?

      1. Andrew: yes .Created VIVO Docker 2 repo - have the Docker components.  In Andrew’s own github

        1. Scrum board:


    5. Harry - is the goal to create a vivo docker in dockerhub?

      1. Ultimately - yes

      2. Point is the VIVO Harry sees in vivo-docker2 fits right into the vision

        1. Fix the build error from the solr-sprint

        2. Could take this image and place it into docker-hub

        3. Could also create a container that takes a local war file and deploys that

        4. So the repo can have a docker-compose.yml file that can get things going

        5. So will the awoods/vivo-docker2 file move into vivo-project or vivocommunity?

        6. Andrew - yes, it will move when ready. Ready to move it now.

    6. Andrew - once sprint-search branch is merged with develop, we should be ready to mint a 1.11 - This can be used for a docker that is pushed to docker hub


Previous Actions


  • No labels