Page MenuHomePhabricator
Create Task
Maniphest T284029

Create/refine user stories for Bernard/WMFDBBackupsMonitor development
Closed, ResolvedPublic
Actions

Description

As a part of T279552
We will be creating some user stories so that we can have some targets to work towards for the mid/final evaluation for GSoC 21

These user stories have been created upon discussion of the project with my mentors Manuel @Marostegui and Jaime @jcrespo
Please have a look and let me know if there are any key features that needs to go into the stories

The following stories provide an abstract view of the requirements/goals that we can work towards for sprint/mid/final evaluations. Based on these stories, we will create some technical Phabricator tickets (eg. Create Flask application skeleton, create API)
These stories aren't meant to be precise (eg. what is freshness of a backup? What is the size/time threshold/buffer? -- this is something we can discuss during development phase and/or can be taken from the existing check_mariadb_backups.py code )

Story 1
As a DB Admin,
I want to see the list of failed backups/freshness of backups by section (s1-s8) in a user-friendly format
So that I can relay important and relevant information to a non-technical person

Story 2
As a Wikimedia dev/any dev,
I want the backups metadata to be gathered through APIs
So that we/anyone can make applications around the data

Story 3
As a Wikimedia ops member,
I want to see freshness of backups of any section (s1-s8) at a glance (eg. single dashboard)
So that I can tell if any of the backups aren’t fresh and take the necessary action to resolve it

Story 4
As a Wikimedia ops member,
I want to see errors of backups of any section (s1-s8) at a glance (eg. single dashboard)
So that I can tell quickly if there are issues with the backups process

Story 5
As a DB Admin,
I want to see the history of backups on any section (s1-s8)
So that I can see an overview of the statuses

Story 6
As a Wikimedia DB Ops member,
I want to know if something is broken in any section (s1-s8) of the backup process
So that I can take necessary action to fix it

Story 7
As a Wikimedia DevOps/CloudOps team member,
I want the program to be configurable with environment variables
So that I can deploy the program easily without modifying any hardcoded values in the program code.

Story 8
As a Wikimedia DB ops team member,
I want to know (at a glance) whether a backup has failed consecutively for a particular section
So that I can investigate the issue quickly

Related Objects
Search...

Event Timeline

h.krishna created this task.May 31 2021, 9:07 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 31 2021, 9:07 PM
h.krishna added a parent task: T279552: Develop a web based monitoring dashboard to improve and monitor existing database backup inventory processes and improve long term maintainability of existing code.May 31 2021, 9:08 PM
h.krishna claimed this task.May 31 2021, 9:16 PM
h.krishna renamed this task from Create user stories for Bernard/WMFDBBackupsMonitor development to Create/refine user stories for Bernard/WMFDBBackupsMonitor development.May 31 2021, 9:23 PM
• jcrespo added a comment.Jun 1 2021, 8:18 AM

@h.krishna to refine the design, I think it would be useful to have an ordered list of more detailed functional and non-functional requirements- ordered by importance. For the following reasons:

  • The user stories are still very high level and mostly abstract, it would be useful to try to give some more details about needs
  • You can agree with the "client" (us) what is more important and what are just "nice to have" features, so there is no misunderstanding there
  • You have focus first on the actual functionality (which is the right thing to do, and the natural thing) but we shouldn't discard the non-fuctional part of it (where should it run, how fast should it return results, how it should be accessed)
  • We could think about the scope of the things that you believe could implement or not in the time assigned
  • We could order them in importance, and make a cut of what can go in and what has to be dropped; and even if things go badly, cut from the botton

We will, or course, help you do this if you think is a useful thing to do :-)

h.krishna added a comment.Jun 1 2021, 9:18 AM

Thanks @jcrespo, Sounds like a plan, will prioritise and make things more clearer and have a think about the scopes and timeframes. (will edit the task and add it in)

h.krishna moved this task from Backlog to In Analysis on the dbbackups-dashboard board.Jun 4 2021, 7:41 AM
h.krishna added a comment.Jun 6 2021, 11:35 PM

A reminder for myself, some more tickets to be made and I need to update the ticket task with new stories, I've made a few basic ones (for tox and code skeleton) but I'll think of some more and add them this week as we go.
Based on our conversation of story priorities, this is some of the non functional requirements (must haves)

  • Should be Python v3.6+ and should be able to run on Debian 10 (python 3.7 is fine but should be backward compatible, 3.9 is fine for Debian 11, test forward compatibility)
  • Should deploy on WMCloud and ensure it runs there
  • Dashboard shouldn't take "forever" to load, 1s loading time atleast
h.krishna moved this task from In Analysis to In Progress on the dbbackups-dashboard board.Jun 18 2021, 4:42 PM
h.krishna moved this task from In Progress to Done on the dbbackups-dashboard board.
• jcrespo closed this task as Resolved.May 25 2022, 4:41 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits