🎨 Persistent logs when GC removes services

[GitHK]

What do these changes do?

Changes log level for the garbage_collector to be set to INFO regardless of the global flag

Question: Why not put the log level to debug? this never works, tried it multiple times and it always somehow reverts back to something else.

As a developer, when trying to answer users' questions like: Why has my service closed? I want to quickly and reliably check the logs and figure out if their project was closed by the GC.

Related issue/s

• dynamic services are being closed without user intervention osparc-issues#1709

How to test

Dev-ops checklist

• No ENV changes or I properly updated ENV (read the instruction)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.9%. Comparing base (cafbf96) to head (0505eba).
Report is 572 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #6403      +/-   ##
=========================================
+ Coverage    84.5%   87.9%    +3.3%     
=========================================
  Files          10    1172    +1162     
  Lines         214   51692   +51478     
  Branches       25     930     +905     
=========================================
+ Hits          181   45452   +45271     
- Misses         23    6065    +6042     
- Partials       10     175     +165     

Flag	Coverage Δ
integrationtests	64.6% <80.0%> (?)
unittests	85.4% <87.5%> (+0.8%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...es/service-library/src/servicelib/logging_utils.py	76.1% <100.0%> (ø)
..._webserver/garbage_collector/_core_disconnected.py	82.2% <100.0%> (ø)
...core_service_webserver/garbage_collector/plugin.py	100.0% <100.0%> (ø)

... and 1179 files with indirect coverage changes

[pcrespov]

Question: Why not put the log level to debug? this never works, tried it multiple times and it always somehow reverts back to something else.

As a developer, when trying to answer users' questions like: Why has my service closed? I want to quickly and reliably check the logs and figure out if their project was closed by the GC.

I would like to follow up a bit with you on this. IMO the GC services in similar in many ways to the autoscaler service in the sense that it observes to get a state and acts on it. There @sanderegg used several techniques to monitor the activity of the service by combining informative logs with prometheus metrics.

[pcrespov]

see comment above

[pcrespov]

I think you are not using correctly caplog. See the example i attach
Take advantage and add more informative logs

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud