Versions Compared

Old Version 5

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Woods

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attendees

(star)  Indicating note-taker

  1.  Don Elsborg  
  2. Huda Khan (star)
  3. Ralph O'Flinn (star)
  4. Andrew Woods Mike Conlon
  5. Benjamin Gross  
  6. Jim Blake 
  7. Steven McCauley
  8. Alex ViggioHarry Thakkar

Agenda

  1. Sprint update
    1. Demo of: 
      Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1685
  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
    1. https://github.com/vivo-community/vivo-acceptance-tests
    2. How to run it

  5. Status of In-Review tickets

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14416
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


    1. Soft balls

      1. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1659
        1. Low-hanging, documentation - Mike Conlon, can you give this one a review?
    2. Regular balls

      1. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1675

        1. New

      2. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1670

        1. Kitio Fofack ? Orcid and i18n

      3. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1656
        1. Is this feature of broader interest?
      4. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1643
        1. Andrew Woods to look into
      5. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1642
        1. Mostly trivial, with conversation around Tomcat version support
      6. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1630
        1. Kitio Fofack to review?

  6. Received

    Expand


    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14802
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1666
       

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

    2. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1665
       
      1. Should be low-hanging

    3. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1663
       

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

    4. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyVIVO-1644
       
      1. Mike Conlon : thoughts on where this stands?


  7. Bugs (1.11)


    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14702
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


...

  1. Sprint update

    1. https://wiki.duraspace.org/display/VIVO/2019-03+Sprint

    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: https://jira.duraspace.org/secure/RapidBoard.jspa?rapidView=36

        2. https://github.com/awoods/vivo-docker2

    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 This can be used for a docker that is pushed to docker hub

...