Count requests per namespace

[majamassarini]

This implementation isn't thread safe. I don't think we need to risk a deadlock just for tracking the trend of requests in a namespace. We can lose some of them.
Also, the aggregation of counts across different workers needs to be done in Grafana.

Should fix packit/packit-service#2912
Merge before packit/packit-service#3026

[gemini-code-assist]

Summary of Changes

Hello @majamassarini, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a lightweight, in-memory metrics tracking system for OGR API calls. Its primary purpose is to gather approximate usage statistics for different services and namespaces, which can then be aggregated and visualized in tools like Grafana. The implementation prioritizes simplicity and performance over strict thread-safety, acknowledging that some data loss is acceptable for trend analysis. This change provides valuable insights into API consumption patterns across various Git platforms.

Highlights

• New Metrics Tracking System: Introduced a new ogr/metrics.py module to track API calls per service type and namespace. This system is designed for approximate metrics, explicitly not thread-safe, and expects aggregation in external tools like Grafana.
• Decorator for Automatic Tracking: A track_ogr_request decorator was added, which can be applied to GitProject methods to automatically record API calls. It extracts namespace and service attributes from the decorated object, with special handling for Pagure projects to include the repository name in the namespace for more granular metrics.
• Integration Across Services: The new track_ogr_request decorator has been applied to numerous methods within the Forgejo, GitHub, GitLab, and Pagure service implementations to begin collecting API usage data.
• Comprehensive Unit Tests: New unit tests were added in tests/unit/test_metrics.py to cover the functionality of the RequestMetricsTracker class, global helper functions, and the track_ogr_request decorator, including edge cases like missing namespaces and silent exception handling.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• ogr/metrics.py
  • Introduced RequestMetricsTracker class for in-memory, non-thread-safe API call counting.
  • Provided get_metrics_tracker for global instance access and record_ogr_request convenience function.
  • Implemented track_ogr_request decorator to automatically log API calls, handling namespace and service type, with special logic for Pagure repositories.
• ogr/services/forgejo/project.py
  • Imported track_ogr_request from ogr.metrics.
  • Applied @track_ogr_request('forgejo') to methods like exists, get_branches, get_commits, get_issue_list, get_issue, create_issue, get_pr_list, get_pr, get_tags, get_sha_from_tag, get_release, get_latest_release, get_releases, create_release, create_pr, set_commit_status, get_commit_statuses, fork_create, get_file_content, get_files, get_forks, and get_sha_from_branch.
• ogr/services/github/project.py
  • Imported track_ogr_request from ogr.metrics.
  • Applied @track_ogr_request('github') to methods like exists, get_branches, get_commits, get_issue_list, get_issue, create_issue, get_pr_list, get_pr, get_sha_from_tag, create_pr, get_commit_comments, get_commit_comment, set_commit_status, get_commit_statuses, get_check_run, create_check_run, get_check_runs, fork_create, get_file_content, get_files, get_release, get_latest_release, get_releases, create_release, get_forks, get_tags, get_sha_from_branch, and get_contributors.
• ogr/services/gitlab/project.py
  • Imported track_ogr_request from ogr.metrics.
  • Applied @track_ogr_request('gitlab') to methods like exists, get_pr_list, get_sha_from_tag, create_pr, commit_comment, get_commit_comments, get_commit_comment, set_commit_status, get_commit_statuses, fork_create, get_branches, get_commits, get_file_content, get_files, get_issue_list, get_issue, create_issue, get_pr, get_tags, get_releases, get_release, create_release, get_latest_release, get_forks, get_sha_from_branch, and get_contributors.
• ogr/services/pagure/project.py
  • Imported track_ogr_request from ogr.metrics.
  • Applied @track_ogr_request('pagure') to methods like get_project_info, get_branches, get_issue_list, get_issue, create_issue, get_pr_list, get_pr, get_pr_files_diff, create_pr, fork_create, exists, get_file_content, get_sha_from_tag, set_commit_status, get_commit_statuses, get_tags, get_releases, get_release, get_latest_release, create_release, get_forks, get_files, and get_sha_from_branch.
• tests/unit/test_metrics.py
  • Introduced TestRequestMetricsTracker for basic recording, multiple requests, empty counts, and reset functionality.
  • Added TestGlobalFunctions to verify get_metrics_tracker and record_ogr_request.
  • Included TestTrackOgrRequestDecorator to test decorator functionality, handling of None or missing namespaces, silent exception handling, metadata preservation, multiple calls, different service types, integration with multiple namespaces, and specific Pagure logic for appending repo names.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a non-thread-safe metrics tracking system to count OGR API requests per namespace. A new decorator, @track_ogr_request, is added and applied to numerous methods across various service implementations (forgejo, github, gitlab, pagure) to enable this tracking. The changes also include comprehensive unit tests for the new metrics functionality, ensuring that the implementation is robust and that failures in metric collection do not impact the decorated functions. My review focuses on improving the typing in the new decorator and refining the testing patterns for better code quality and maintainability.

[centosinfra-prod-github-app]

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/3951bf9ba9284ef38d5a2c4a298c4e38

✔️ pre-commit SUCCESS in 3m 24s
✔️ ogr-tests-pip-deps SUCCESS in 11m 19s

[centosinfra-prod-github-app]

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/8a3973d754da4a2c8d24724125e36229

✔️ pre-commit SUCCESS in 3m 32s
✔️ ogr-tests-pip-deps SUCCESS in 12m 06s

[betulependule]

I like this implementation.

Regarding it not being thread-safe, I'm thinking, can't we just add locks whenever the _counts variable is being written to and read from? It doesn't seem like much of an issue, but I might be missing something. I understand that it would be nice to avoid introducing a deadlock to the code. 😅

[mfocko]

Why are we not going with metaclasses here? it might be easier to just wrap everything, like we do for the exceptions, instead of this copy-paste…

At the same time, the simple tracking of github / gitlab seems to be enough, but with both GitLab and Forgejo there can be self-hosted instances, which kinda breaks the counters?

I'm also a bit afraid that this is something that's quite obviously service-specific, so I'm not sure how it fits the ogr in general.

[majamassarini]

Why are we not going with metaclasses here? it might be easier to just wrap everything, like we do for the exceptions, instead of this copy-paste…

It would be nice to be able to use metaclasses, but I don't think we have a reliable/simple way to decide which methods need wrapping using metaclasses. This way is clearer/more explicit, from my point of view.

At the same time, the simple tracking of github / gitlab seems to be enough, but with both GitLab and Forgejo there can be self-hosted instances, which kinda breaks the counters?

True, I missed that. Thanks! I can add the project url.

I'm also a bit afraid that this is something that's quite obviously service-specific, so I'm not sure how it fits the ogr in general.

I partly agree. If the service weren't using only ogr, we'd need more logic there. But since most requests (if not all) go through ogr, I don't see why not. Counting requests where they're made seems correct to me. Also, ogr is a library, so this feature could be useful to other services.

[majamassarini]

Regarding it not being thread-safe, I'm thinking, can't we just add locks whenever the _counts variable is being written to and read from? It doesn't seem like much of an issue, but I might be missing something. I understand that it would be nice to avoid introducing a deadlock to the code. 😅

I think the implementation would be simple enough, but I'm concerned we might encounter deadlocks occasionally; when a task fails, a worker is killed, or in other edge cases. I'd like to avoid these situations since we only need a general trend of our request volume.

[centosinfra-prod-github-app]

Build succeeded.
https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/packit-service/buildset/9ed0b93808954635bcc33c6229e6367f

✔️ pre-commit SUCCESS in 3m 22s
✔️ ogr-tests-pip-deps SUCCESS in 11m 21s