Date

23 Jan 2018

7am PST / 4pm CET

Meeting Link

Note we're using Zoom now:

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/737202874

Or iPhone one-tap :
US: +16699006833,,737202874# or +14086380968,,737202874#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
Meeting ID: 737 202 874
International numbers available: https://zoom.us/zoomconference?m=F0kj5u6u0wFxr7Xfz5NKZxl0xyLhuTPF

Attendees

All are welcome

Goals

See discussion items

Discussion items

Time	Item	Who	Notes
10m	Agenda and action item review	Josh Zamor (Deactivated)
15m	Approve req and separate resource	Mateusz Kwiatkowski	Approval notes and quantities fields - separate resource
15m	Feature based dependencies	Josh Zamor (Deactivated)
~~15m~~	UI Application Entry Point and Bootstrap	~~Nick Reid (Deactivated)~~
10m	Equals and hashcode followup (if time)	Chongsun Ahn (Unlicensed)

Notes

Approve req and separate resource

approved qty and remarks - these two fields only used during approve process
there is a draft to Requisitions - so to update the approved qty you still need to leverage the draft
approval requisition line item - we'd want an aggregate
- status: authorized / approved?
- a flag for draft?
We'd need the regular requisition - we'd need it to display the grid
- in a batch, some of the columns aren't needed (could we a resource for batch approval)

Next step: create a PoC RESTful design, and present next time

Feature based dependencies

Goal: We want to leverage our service architecture to enable independent:

Develop features in services by different teams
Deploy services based on functionality desired

Why independence?

Development teams may progress independently on services:
- build time dependencies don't hold a dev team back (e.g. not every service needs the same version of spring boot).
- We may build our Services to turn functionality on/off/do something else should functionality provided by another service we depend on, not be available
Deploying a Service should be a run-time choice for an implementer - i.e. if an implementer doesn't want the functionality some service provides, they should be able to choose not to deploy it.
1. e.g. I want Requisitions, but I don't want Stock Management, and as an informed implementer I know that means that no Stock Management fields will be available in Requisition if I choose not to deploy Stock Management.
2. Upgrading a Service, even though the implementation doesn't use it, is a burden on the implementation:
  1. Implementer's time to upgrade, maintain, monitor, etc
  2. Computing Resources

Goal: is to allow for features to turn on/off based on if a Service is available.

Available could mean:

Service was not deployed - this is the one we're trying to solve
Service was deployed, but not serving requests - typical solutions to these include circuit breaker, bulkhead, etc (we don't need to solve for these today)
- Service simply isn't reachable
- Too many requests
- Not yet ready to serve requests

Solutions:

Feature-based dependencies / flags (lack of a better word)
- re-uses / leverages RESTful HTTP approach (favored API re-use)
- we want to give the implementer and service developer the ability to turn features turn on / off, and we do that by knowing the deployments intent - a Service is available if it was in the deployment descriptor (docker-compose)
- we need to spike on how to:
  - read/write solution (current preferred approach due to race condition using service registration)
    - read the docker-compose (docker-compose config --services) and create a feature flag based off services deployed
    - we need to publish (consul KV) those flag statuses and consume those in our services (constantly checking? No, config doesn't change. We want on startup - onetime)
    - Above reading/writing of these flags to be used in feature-based dependencies is covered in OLMIS-3906 - Getting issue details... STATUS
    - the above avoids the race condition inherent in using the knowledge in Consul available through service registration,
  - using service registration in Consul (would be tricky):
    - could use a timeout solution - we don't have a way in spring boot to actually stop serving requests.
    - registration could be done very quickly - and so most likely before detection is done, everything is registered.
    - auth is constantly re-checking consul for services deployed (however how would we solve for the reference UI / keep a consistent user experience across services detecting what is available)
    - however we don't we don't have a solution to the race condition:
  - Requisition to Stock Mgmt is a good first step to implement (would spur the discussion about which "features" turn off)
    - all stock mgmt fields including reasons for losses and adjustments

Equals and hashcode (re-hashed)

Strictly for DTOs, we want to include all properties because we want to generate etags (and most straightforward approach is through hashcode of Object). One of the main issues is the DTOs weren't including the id fields in the BaseDTO.

Did a quick spike in reference data, for dto's not using the id fields. The main issue appears to be some tests that fail because they're using equals methods. Most can be easily solved. One in particular, the Orderables class might not be easy to solve.

Summary: Seems like we're close, but it's not quite trivial work in Reference Data.

General advice is to fix as we go.

if you are implementing the caching strategy, fix DTOs as you go.

Next steps:

add http cache to style guide, cross-link to performance section: http://docs.openlmis.org/en/latest/conventions/performanceTips.html
mention if you're adding http cache, then check the DTOs

Action Items

Mateusz Kwiatkowski to create a Proof of Concept RESTful design for requisition approval as a resource, and present next time
Chongsun Ahn (Unlicensed) to add docs on http caching / dtos