Versions Compared

Key

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

...

  1. Questions/Issues/Pull requests/Announcements
    1. VIVO track at the CRIS conference - the submission closed
    2. A new GitHub VIVO community repository - https://github.com/vivo-community/vivo-ansible-vagrant
  2. Spamming at the GitHub repository -  https://github.com/vivo-project/Vitro/pull/211#issuecomment-1067547298
  3. DSpace-VIVO integration
    1. DSpace-VIVO integration task force
  4. The February sprint - https://github.com/orgs/vivo-project/projects/2/views/1
    1. recap of the sprint
      1. number of participants
      2. result - https://github.com/vivo-project/Vitro/tree/sprint-dynapi-2022-feb-staging
      3. well done vs might be improved
      4. next steps 
  5. Update of the Roadmap - https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing

Notes

Sandra Mierz: Ansible role for VIVO installation focused on automating VIVO installation.  Now whole process using Ansible playbook.  Also includes system requirements installed for your VIVO machine.  Afterwards, installs system.

https://github.com/vivo-community/vivo-ansible-vagrant

Playbook should be compatible with Debian, Ubuntu, RHEL machines

Sandra Mierz created an Ansible playbook for creating virtual machines that run Ubuntu set-up for VIVO app deployment. It also works for other debian based linux systems. Sandra and William quickly discussed the difference between deployment with VirtualMachines, which would be set up with Ansible, and deployment via container created with docker images. As William suggested, docker image should be fine, but standalone docker engine should not be used for production deployment, reather to use some sort of orchestration tool like Kubernetes or Docker Swarm.

Dragan mentioned a spam-like comment left on one of closed pull requests.

Since DSpace-VIVO integration members were not present at the call, we skipped the section where they were supposed to present their work so far.

Dragan then talked about February sprint results. Although progress on dynamic api was made, there still is no finished feature to present. We went through the notes taken on the last sprint meeting (sprint retrospect). Documentation for VIVO Dynamic API is not yet done, but Dragan plans to start with that this week. There are some tasks left over from this sprint that should be finished before the next sprint starts. Such tasks are tasks from Execution track, and iterative actions.

William suggests that although the base sprint branch wasn’t used, it still needs to be there. The fact that the base branch wasn't needed this time, does not mean that it was a bad thing. He suggested that planning could have been a bit more rigid. Dragan thinks there is a space for improvement in planning of a sprint, but feels that the planning was quite good considering the complexity of dynamic api task. A lot of planning was done during the sprint, which in ideal case would not happen. 

Some tracks for the next sprint could be security, validation, and user interface for creating new actions, and maybe data ingestion via dynamic api (this might be out of next sprint’s scope). Dragan suggested may 16th as the starting point for the next sprint. That's after the CRIS conference.

William and Kevin can't participate on those dates, since they are already committed to other sprints. 

William and Georgy suggested having some sort of pool/questionnaire for implementers, to see what features they use, and what features they want to see added.

Draft notes on Google Drive

...