Date

Call-in Information

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

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe
  2. Ralph O'Flinn 
  3. Georgy Litvinov 
  4. Nicolas Dickner 
  5. Michel Héon 
  6. Huda Khan 
  7. William Welling
  8. Don Elsborg (star)
  9. Benjamin Kampe 

Agenda

  1. How can we make a push to get to RC1?
    1. Open pull requests:
      1. https://github.com/vivo-project/VIVO/pulls
      2. https://github.com/vivo-project/Vitro/pulls
    2. New issues
      1. Additional thoughts/results about precise subquery default for TDB or not?
    3.  Release Testing - 1.12.0
      1. How can we encourage community testing?
      2. Can we simplify documentation for new users?
    4. Documentation
      1. VIVO Build and Installation Process - needs reverting/updating
      2. Using VIVO's Internationalization (i18n) Features - separate the step-by-step details from overview?  Make more prominent?
      3. Simplifying end-user/installation instructions while retaining details for developers
    5. Blocker issues
      1. issuekey summary issuetype created updated duedate assignee reporter priority status resolution

        Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Embracing standard approaches : how do we better align VIVO with other software and make it easier to adopt / install / develop for without having to learn the "VIVO way"?
    1. Possible topics:
      1. Horizontal scalability
      2. Deployment
      3. Configuration : files / environment variables / GUI settings
      4. Frameworks / Spring
      5. Editing / form handling
      6. Adding custom theming without customizing build
  3. Post-i18n priorities
    1. VIVO-in-a-box
    2. Ingest / Kafka
    3. Advanced Role Management
    4. Moving Scholars closer to core - next steps

Future topics

  1. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be?
  2. Incremental development initiatives
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

Tickets

  1. Status of In-Review tickets

    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.

Notes

  1. Close to an RC1, how do we get over the hump.
    1. Need to get PR’s to get into the alpha
    2. Ralph, could always revert if a PR has issues.
    3. Need to remove the last 2 commits out of Main in VIVO and VITRO because these need to be in Alpha
  2. Brian - Sitemap.xml is broken. He will add a PR for that . VIVO-1910
    1. This needs to be worked on.
  3. More reviews needed VIVO, also 2 reviews for Vitro - 215 and 216. VIVO-1966 and VIVO-1967. On VIVO side - VIVO-1969 and VIVO-1956 ( 1956 didn’t make it to blocker status in Jira, this is because of it being Open vs In review status )
    1. Ralph will try to review some of these.
  4. What is a reasonable timeframe?
    1. Ralph - if we can wrap by next call, We can have a yeah/neah vote and move towards mid-April
    2. If we can get rc out by end of march. Then if RC2 is one we can ship, there’s a chance we can make the release by end of April.
    3. Ralph will review outstanding PR’s and approve
  5. Don will review this PR for a VIVO upgrade that doesn’t use languages -https://github.com/vivo-project/VIVO/pull/225
  6. PR 227 - this should be easy to test. Add things in the GUI and make sure things get indexed.
  7. Last week Benjamin discovered that using the settings is only used with the SDB store. These subqueries get filtered with SDB. He noticed that queries are also faster with TDB. There is a setting in runtime.properties which sets - use-precise-subqueries = true. Should this be the default setting in 1.12
    This setting isn’t documented in 1.12.  This allows for neat looking queries which uses “optionals” for sdb which doesn’t handle optionals well. Again, there seems to be a speedup with this even in TDB. Brian ran test queries in TDB store with 6 million entries, he noticed a dramatic difference. Looking at publication on its own with 10-15 authors, and retrieving authors for pubs went from .5 second to 1 millisecond. This raises the question if we should explore this in the default. 
    1. Don - can we just place the property into runtime.properties and set it to the default. Also add a comment to it.
    2. Brian - there is no ticket assigned to this.
    3. Don - can we submit this to Apache Jena as a ticket?
    4. Brian - should we set this as a default to be true even for TDB?
    5. Ralph - go ahead and change the default setting in the candidate to be true. 
      1. No objections.
      2. Any issues for non-Jena? Nobody knows and we don’t test non-jena. Was wondering about sites like Cineca which uses blazegraph
      3. Ralph - make a note in the release notes for those not using Jena to at least test this.
      4. Also - the use-precise-subquery enhancement was made in 1.10. So there could be performance improvements. 
      5. Not sure if there were any non-performant queries prior to 1.10. Ralph thinks he recalled there being improvements.
      6. Brian will create a ticket and work in the enhancement
  8. Wiki Documentation 
    1. Ralph will finish working on docs if it was sorted once Brians PR’s are undone and then sent to the Alpha branch. It will still support the new docker-compose.
    2. Will get new installation instructions into the new docs
    3. Will revert the commits with the war based components including unpacking the home dir. Going back to the original process This was Andrews approach for the new deployment strategy. Did maintain both github actions and also the docker file which publishes the docker image everytime we publish to main. Also the docker-compose is retained.
  9. Michel wrote docs how an end-user can use the i18n features. Discussion where this doc lives now. Seems like Ralph will copy this info to the right location in the wiki. Brian has concerns if the end user docs are in the right place to make it easy to find. Ralph is re-sorting this. Everything was copied from the 1.11 to 1.12, not sorted yet.
    1. Ralph - let’s discuss more next week - action for next week
  10. Priorities for moving VIVO to standard approaches
    1. War files vs. installation
    2. Horizontally scalable - in embedded triple store this isn’t an option
    3. William - near term want to make it easier to deploy/use/develop where they don’t have a staff. This needs to happen quickly. But also need to keep current implementers on board and future proof it.
    4. Brian - with clients it’s a stumbling block with issues like where it gets hosted. So playing nicely with cloud providers.
    5. William - we need a self-contained deployment. So for AWS for example.
    6. Don - can we make this service oriented - so we can use an AWS service for search, database, and java container
    7. Ralph - in microsoft Azure - it recognizes the various services.
    8. William - AWS uses AWS elastic beanstalk. But this isn’t easy
    9. Don - eg use AWS elasticsearch container, also use RDS mysql container for DB
    10. William - AWS offers a SOLR container.  
    11. Ralph - Azure allows powershell scripting
  11. Brian - So we can have tomcat run in a JRE.
    1. William - tomcat and jetty -  we could have an embedded container, most of these options have dependency injection. This would be a big enhancement.
    2. Brian - can we move towards an embedded container? Are there big issues with Freemarker and templating which might not work in an embedded container. 
    3. William - Spring is auto-configured and has its templating engine. There are alternatives but this would go a different direction. Believes Spring Boot is the best direction. This changes a lot, controller annotation, service annotations. This leans on dependency injection a lot. Mappings, route, etc.
      For development just do maven Spring Boot run and it’s up.
      Can’t estimate on level of effort but might be significant.
    4. Brian - straw poll - worth it?
      1. Let’s analyze - need more time to discuss
      2. Don - want to understand the value add, outside of new tech
      3. Brian/William - how to make it easier and more maintainable.
      4. William - easiest path seems to add technical dept and bloat. Maintenance and longevity of the code is an argument to make to management. 
      5. Michel - danger of introducing too many new tech is that we change the architecture of the software. We can’t remove various components easily.
      6. William - just Spring Boot additions isn’t a drastic architectural change. Bigger changes are modularization. 
      7. Ralph - issue also is who will do this. So an institution saying I will donate time to a project for a certain amount of time.
    5. Gregory - should think about guidelines and goals for institutions. So if one wants to use cloud or their methods, to set up the guidelines for them to use. So we should understand what our main goals are, guidelines would help.
    6. Ralph: Data ingest - next meeting is April 1

Draft notes on Google Drive



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.