2017-11-14 Meeting notes

Date

14 Nov 2017

7am PST / 4pm CET

Meeting Link

https://meetings.webex.com/collabs/#/meetings/detail?uuid=M0UUCAJ68OYLPMKAROOE9PJSBW-3O29&rnd=897752.12165

Toll: +1-415-655-0001

Number:  199 948 686 

Attendees

• Elias Muluneh
• Ben Leibert
• Sebastian Brudziński
• Brandon Bowersox-Johnson
• Chongsun Ahn (Unlicensed)
• Paweł Gesek
• Paweł Albecki (Deactivated)
• Mateusz Kwiatkowski
• Josh Zamor
• Nikodem Graczewski (Unlicensed)
• Łukasz Lewczyński (Deactivated)
• Klaudia Pałkowska (Deactivated)

Goals

• Feedback on Demo-data loading approaches
• Review error message handling from dev forum

Discussion items

Notes

Demo Data

• Current:  on wiki - Dev writes JSON files which are turned into SQL files (generated)
• Biggest pain points: 
  • Dev has to generate their own UUID
  • Many tools use CSV, people can use CSV, but CSV to JSON is currently a slow process
  • Dev has to ensure loading-order is correct
• Bottom line:  Developer is needed, non-devs can't realistically manage this directly.  Even for a dev this is slow.

New approaches:

1. Merge ref data seed tool into each service
   1. Some great advantages (hit the major pain points)
   2. Difficult to put into a service
   3. In our startup of a service, there is a timing issue - many testing tools rely on demo-data to exist before starting
   4. Code references (for ref integrity) are configurable in the mapping file
2. Use the performance data approach
   1. CSV files - generate with Mockaroo
   2. Hits all the major pain points
3. Nifi
   1. https://nifi.apache.org/
   2. Has the same startup issue

UUID's generated:

• Contract tests and performance tests use those UUID
• Even some manual QA tests use UUID (maybe legacy issue - we want to re-write these using the admin UI)
• So:  changing existing UUID's could be a big problem
  • If the UUID's could make the tests smarter - wouldn't fix QA tests but then we wouldn't have this hard-coded / human made UUID issue
• Could Excel do this!?

Error responses - consistency

Dev forum had already focused on option 3 - use the top level error message with some section below that.  Keeps backward compatability.

Further we discussed the idea for nesting (details within details) which seems like something we could do if needed.  Ideas for usage was something along the lines of semantically structuring error messages (e.g. there's an error, there's an error in the budget, there's an error in budget line item 5) or directly down to a line item.

Between fieldErrors or renaming it to details we felt there's value in just keeping it a direct "fieldErrors" name.

Azure

• $5000 credit / year for any non-profit in certain countries (more the developed countries - USA is in the list)
• Opening two data centers in Africa in 2018.
• Non-technical decision makers within countries are very hesitant to move their data out of their country. AWS is unknown outside of the technical community and therefore untrusted. By contrast, stakeholders are familiar andcomfortable with Office365. Selling them on the use of Microsoft’s cloud, which they probably already use, is likely a lot easier than selling them on AWS.

• Intuitive and modern UI – great for organizations which are less technical but nevertheless interested in maintaining their own OpenLMIS instance.

• Users can schedule recurring/automated backups for the days/times of their choice. 
• Comes with built-in monitoring and alerting - may obviate the added complexity of Scalyr.
• Not sure about competitor to Amazon ECS or Kubernetes / Swarm mode

Action Items

• Sebastian Brudziński: followup with Chongsun on dmeo-data loading and ref data seed tool
• Paweł Albecki (Deactivated): writeup decision on error messages and put into our style guide (RTD)