2020-04-21 Sprint Transition
Date
Apr 21, 2020
Participants & Internal Stakeholders
@Felimone Amone Junior
@Matthew Kumbuyo (Deactivated)
@Chongsun Ahn (Unlicensed)
@Christine Lenihan
@Ben Leibert
@Sebastian Brudziński
@Aleksandra Ciesińska
@Oskar Hinc (Unlicensed)
Retrospective
It’s great that we were able to incorporate the 3.9 release, especially since doing so resolved several high-priority tickets we had. Overall, it took about 2 days of Oskar’s time and 6 hours of Aleksandra’s to perform the upgrade.
On the one hand, unforeseen issues related to Superset and the data-pump seemed to significantly slow our progress. On the other hand, we finished many more tickets this sprint than last.
The regressions we encountered were largely to due to the 3.9 upgrade, and were included within the approximately 3 days it took to perform the release. Going forward, we should better document SELV’s specific configuration so as to improve our ability to incorporate releases.
@Oskar Hinc (Unlicensed) did a phenomenal job of quickly ramping-up last week. He became productive quite quickly. This last sprint seemed even better to him, though, given that he’s now completely onboarded.
Showcase
@Aleksandra Ciesińska finished and demoed:
@Oskar Hinc (Unlicensed) finished and showcased:
@Ben Leibert finished and reviewed:
Planning
Determining how to proceed vis-à-vis the data-pump is our highest priority. The issues we have regarding it are that:
Exceptions cause it to silently shutdown and thereby break the Batch Approval page. We could address this by having Scalyr raise an alert whenever an exception is logged. In order to have OpenLMIS notify end users that there’s a known problem with the Batch Approval page, though, we’d likely have to monitor the API reliant on the data-pump.
Attempts to insert duplicate keys are causing the data-pump to shutdown.
Attempted insertions involving dissimilar data-types are also causing the data-pump to shutdown. We probably didn’t encounter this before before because the relevant tables largely lacked data.
Our options are to:
A) Continue trying to use the data-pump. @Chongsun Ahn (Unlicensed) is willing to field questions posted to the tech forum. The overall time and effort requisite to fix the issues is unknown, though, and seems likely to exceed the project’s remaining seven days.
B) Postpone use of the data-pump for now. This would require simple SQL changes, which have already been made as part of Oskar’s exploratory work, along with 1 - 2 days of refactoring the Batch Service’s integration tests.
Discussion:
Although the data-pump can be configured to accommodate schema changes, our currently isn’t. Instead, as part of any upgrade, the dev team still has to manually check for and accommodate such change. Although use of a pump still certainly seems like an architectural ideal, we can’t identify offhand any concrete benefits to it at the moment.
Option A seems highly risky given how little time we have. It’s unlikely that we can address the known issues with the data-pump, upgrade the Batch Approval page to gracefully inform users of when it goes down, and thoroughly test the developed solution within the next week. Ideally, a pump would be introduced toward the beginning of a project so as to allow for its thorough and ongoing testing. Such testing seems necessary in light of the issues we’ve encountered but, unfortunately, isn’t something we can currently accommodate.
Option B is more likely to yield a robust solution given our time constraint. We’ll thus take it. Because use of the pump remains a longterm goal, though, @Oskar Hinc (Unlicensed) will post our current issues regarding it to the tech forum. The insight gleaned there will help us reincorporate the pump at a later stage as time permits.
Action Items