2019-06-11 TC Meeting notes

Date

6am PST / 4pm CEST

https://zoom.us/j/211353423

Attendees


Discussion items

TimeItemWhoNotes
5mAgenda and action item reviewJosh Zamor



15 mCollecting notes on next steps on reporting stackJosh Zamor

We have:

  • Production Readiness 2/2 - OLMIS-6182 - Getting issue details... STATUS
  • Data pumps
    • Reduce brittleness
    • Streamline how data moves
    • How could we apply the strangler pattern to move incrementally to a different approach


Can we focus everything into production readiness #2 epic?


PouchDB and flaky testsChongsun Ahn (Unlicensed)

Testing that involves the wrapper for PouchDB causes the UI tests to be flaky (what we sometimes refer to as random failures):

  • Can we improve the reliability?
  • Is our PouchDB wrapper good?  Is it a leaky abstraction?  etc
  • Are we favoring coverage > reliability?
  • (more to add)
10mOrderable versioning (fulfillment)Klaudia Pałkowska (Deactivated)
  • Design of Order, Shipment, PoD line item use of Orderable versioning
  • Incrementing orderable version

Reducing Jira costsSebastian Brudziński / Wesley Brown
(next time)Schedule for July 9th and on

Overlap with Governance committee every other week

  • Should we extend the call to 90 minutes? We don't have to use full 90minutes if there are no agenda topics, but it would be good to have more time reserved in case - Sebastian Brudziński
(next time)Jenkins monitoring
Show only if time, roadmap for influxdb
(next time)Look at streaming from Casper

Notes


Pouch DB and flaky tests


  • Ticket on tests failing from PouchDB:  link (Josh Zamor find this search for local database failing randomly)
  • Quarantining tests that are failing (disable and create tickets to fix)
  • We expect that if we follow the patterns laid out now, that they won't be flaky.  Wrote a tool to convert tests from JS promises, to Angular JS promises which work Jasmine.


Orderable incrementing


  • Context is Fulfillment service and use of versions in Orderable
  • New class - reference the version # along with orderable id
    • works as nothing is snapshotted (mostly)
  • One thing that is snapshotted today is useVVM in POD Line item
    • Suggestion to remove the snapshotting, retrieve it directly from Orderable's (extra data)
  • Will need to update reports (pick pack list and printing orders)
  • Josh Zamor:  take a look at https://github.com/OpenLMIS/openlmis-fulfillment/blob/master/src/main/resources/schemas/referenceObjectDto.json
  • We might want to have a separate reference to orderable id and version # in json fields - make it easier for caching
  • On incrementing:
    • trigger?
    • generated version id (marked as it doesn't work)
    • hibernate envers
    • We do have this at the service level, there is an issue to move it to repo layer (avoid race-condition)
    • Josh Zamor: take a loot at this today
    • Paulina Buzderewicz:  create a forum post, with a link to the ticket


Jira costs

  • Zephyr is expensive - considering ideas to a different tool (others don't support every feature we're using)
  • Idea to have separate Jira instances:
    • cloud instance to another could use a full backup...  (look at link in table)
    • managing access would add overhead
  • We could turn it off for a couple months
    • think it might come back when we turn it back on
    • wouldn't be able to enter new test cases while it's off


Action Items

  • Josh Zamor schedule future tech comm calls for Zoom and calendar

OpenLMIS: the global initiative for powerful LMIS software