2019-12-10 Sprint Transition
Date
Dec 10, 2019
Participants / Stakeholders
@Felimone Amone Junior
@Matthew Kumbuyo (Deactivated)
@Chongsun Ahn (Unlicensed)
@Christine Lenihan
@Ben Leibert
@Sebastian Brudziński
@Aleksandra Ciesińska
@Mateusz Kwiatkowski
Retrospective
The team has had a sufficient number of tickets to work on, and they’ve been well prioritized and clear. A few minor questions arose, but they were rapidly addressed. The team has thus been able to progress without any significant issues.
Showcase
@Aleksandra Ciesińska finished and described:
Although the database-restoration process has been tested on the dev and production servers, we should retest it after we have a more thorough set of reference-data to work with or have had a chance to load the Core’s performance-dataset.
@Chongsun Ahn (Unlicensed) mentioned that backup files can get pretty large - he once encountered a 17GB one associated with Tanzania’s system, eLMIS. (At around 50MB, the backups currently created by the production instance of SELV-Classic are pretty small. We should nevertheless keen an eye on the size of those created by SELV v3, though, and work on a solution which won’t require impractically large file-uploads if and when necessary. Ben will create a ticket dedicated to the work.)
Speaking of files size, Jenkins' restore job expects a .zip file comprised of a single .sql file. Zipping the file reduces its size, of course, and corresponds to the way in which backups are stored by the backup mechanism.
@Mateusz Kwiatkowski demoed:
We use DNS entries rather than email to verify ownership of the selv.org.mz domain.
Planning
For now, use of a single page should suffice. We have several analogous pages for the Angola project in order to selectively share passwords with external partner organizations. VR is primarily responsible for SELV, though, and therefore has no need to share passwords externally for now.
@Felimone Amone Junior will post additional CSV file to the page tomorrow.
We’ll use ExtraData to add the properties described by . This will allow us to easily offer the new feature by the end of January, prior to OpenLMIS' 3.9 release. Because we don’t plan to add the properties to the Core’s backend, we’ll exclusively expose them within SELV’s UI. Later, if reliance on ExtraData meaningfully degrades performance, we’ll consider adding the new properties to the reference-data service’s orderable domain object. At that point, if we wanted to update Core’s UI as well, we could potentially add a flag to each orderable specifying whether it needs cold storage. Setting the flag to true would case the new properties to show in the UI as shown in SELV3-13. The flag would be set to false by default, though, allowing existing implementation to see no such change/addition to the UI unless they wish.