Adding SQList as client storage solution

[lotif]

PR Type

Feature

Short Description

Clickup Ticket(s): https://app.clickup.com/t/868bv4yn5

In this PR I am introducing SQLite as a solution for the FLorist client to store sensitive information about the FL client. List of changes:

• Making the florist/api/db/client_entities.py which will contain both the SQLite entity definitions and the methods to connect and access the DB.
• Renaming florist/api/db/entities.py to florist/api/db/server_entities.py
• Removing pid and log_file_path from the ClientInfo MongoDB entity
• When the FL client starts, instead of returning the pid and log_file_path, it will now save those to the database
• On both client's stop and get_log functions, change them to receive the client UUID instead of the pid or log_file_path respectivelly
• Changing the set_pids function to set_server_pid as it now only saves the server's PID.

Tests Added

Fully unit and integration tested

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 94.39252% with 6 lines in your changes missing coverage. Please review.

Project coverage is 94.29%. Comparing base (ffd6a24) to head (be43817).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
florist/api/db/client_entities.py	95.08%	3 Missing ⚠️
florist/api/routes/server/job.py	66.66%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #159      +/-   ##
==========================================
+ Coverage   89.33%   94.29%   +4.96%     
==========================================
  Files          24       25       +1     
  Lines        2578     2647      +69     
  Branches      216      216              
==========================================
+ Hits         2303     2496     +193     
+ Misses        275      151     -124     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nerdai]

Just a few comments, nothing majorly glaring from what I can see. So many tests tho -- very nice!

[nerdai]

just making sure we want to change to uuid for this over pid?

[lotif]

Yes, it's one of the goals of having storage on the client, so we don't pass things like PID and local file paths around.

[nerdai]

Ah okay gotcha. Thanks!

[nerdai]

Quick q: are we concerned at this stage (or at any stage) that we're writing these objects to local? I guess they're not very big objects and we're not writing that often are we?

[lotif]

No, they are just supposed to contain meta-information about the flower clients so we can have some control over them on the FLorist side. This is not supposed to contain full application information or even be a fully trusted source of data, it's just a way to avoid sharing sensitive information with the server side of things. I tried to find the cheapest and easiest thread-safe way of doing that and SQLite was the best I found after I found out TinyDB is not thread-safe.

IMO it should only contain information about the client that is not allowed to be shared to the server. In this first case here, it will contain PID and a local file path to the client logs, but I can also see the local model file paths being stored here in the near future. Anything else that is not a problem being sent to the server should be sent to the server for storage on MongoDB.

[nerdai]

Thank you for this context! I remember you talking to us about TinyDB lacking concurrency (lol). Based on this context and your implementation, I think this is pretty good! 👏🏼

[nerdai]

looks good from my perspective!