2019-06-11 TC Meeting notes

Date

Jun 11, 2019

6am PST / 4pm CEST

Meeting Link

Attendees

Discussion items

Time	Item	Who	Notes

Time	Item	Who	Notes
5m	Agenda and action item review	@Josh Zamor (Deactivated)
15 m	Collecting notes on next steps on reporting stack	@Josh Zamor (Deactivated)	We have: Production Readiness 2/2 - https://openlmis.atlassian.net/browse/OLMIS-6182 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 tests	@Chongsun 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)
10m	Orderable versioning (fulfillment)	@Klaudia Pałkowska (Deactivated)	Design of Order, Shipment, PoD line item use of Orderable versioning Incrementing orderable version
	Reducing Jira costs	@Sebastian Brudziński / @Wesley Brown	Anything we can do to cut on costs? Especially addon-wise. What are all our users? ~200 active accounts Possibly have two separate Jira instances? One dedicated only to development, that would have Zephyr and other needed apps installed https://confluence.atlassian.com/jirakb/how-to-migrate-projects-from-one-jira-cloud-application-to-another-779160766.html
(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 (Deactivated) 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 (Deactivated): 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 (Deactivated): 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 (Deactivated) schedule future tech comm calls for Zoom and calendar