New Patroni Integration #2575
New Patroni Integration #2575
Conversation
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
|
|
||
| class PatroniCheck(OpenMetricsBaseCheckV2): | ||
| DEFAULT_METRIC_LIMIT = 0 | ||
| STATE_FILE = "/tmp/patroni_check_state.json" |
There was a problem hiding this comment.
🔵 Code Quality Violation
Do not hardcode a temporary file name; use the tempfile module instead (...read more)
Do not hardcode the names of temporary files or directories. This may constitute a security vulnerability because an attacker might use that name to create a link to a file they want to overwrite or read.
Instead of hardcoding values, use the tempfile Python module to create unpredictable names.
Learn More
| WORKDIR /app | ||
| COPY openmimic.py . | ||
| COPY metrics.txt . | ||
| RUN pip install Flask |
There was a problem hiding this comment.
⚪ Code Quality Violation
| RUN pip install Flask | |
| RUN pip install --no-cache-dir Flask |
use --no-cache-dir to avoid caching (...read more)
This rule states that Dockerfiles should not use a cache when installing packages. When building Docker images, Docker has a built-in caching mechanism that reuses instructions from previous builds, which can speed up the build process. However, when installing packages, this can lead to outdated packages being used, which might have security vulnerabilities or bugs.
It is important to avoid using a cache when installing packages because it ensures that the latest version of a package is always used. This reduces the risk of security vulnerabilities and bugs, and ensures that your application has the most up-to-date and secure dependencies.
When installing packages with pip in a Dockerfile, use the --no-cache-dir option. This tells pip not to use a cache when installing packages, which ensures that the latest version of the package is always used. For example, instead of writing RUN pip install django, write RUN pip install --no-cache-dir django.
|
|
||
|
|
||
| if __name__ == "__main__": | ||
| app.run(host="0.0.0.0", port=8888) |
There was a problem hiding this comment.
⚪ Code Vulnerability
do not listen on all interfaces (...read more)
Avoid giving access to your resources to all connected interfaces. Instead, bind the resources on a specific interface. Running the server on 0.0.0.0 exposes the server publicly.
Learn More
|
|
||
|
|
||
| @app.route("/metrics") | ||
| def passResponse(): |
There was a problem hiding this comment.
⚪ Code Quality Violation
| def passResponse(): | |
| def pass_response(): |
use snake_case and not camelCase (...read more)
Ensure that function use snake_case.
This rule is not valid for tests files (prefixed by test_ or suffixed by _test.py) because testing requires some camel case methods, such as, tearDown, setUp, and more.
Learn More
| WORKDIR /app | ||
| COPY openmimic.py . | ||
| COPY metrics.txt . | ||
| RUN pip install Flask |
There was a problem hiding this comment.
⚪ Code Quality Violation
package Flask should have version pinned (...read more)
This rule emphasizes the importance of pinning versions when using pip to install Python packages in your Dockerfile. Pinning versions means specifying the exact version of the package you want to install. Without pinning, pip installs the latest version of the package, which may not be compatible with your application.
Pinning versions is crucial for maintaining the stability and reproducibility of your Docker images. Without pinning, your builds could suddenly start failing because of a new package version that introduces breaking changes. Your application could also behave differently or even fail when running in different environments, due to variations in package versions.
To avoid these issues, always specify the exact version of the package when using pip install. For example, instead of RUN pip install django, use RUN pip install django==1.9. If you have a list of packages to install, you can put them in a requirements.txt file with their versions pinned, and then install them with RUN pip install -r requirements.txt. This practice will ensure that you always know exactly what versions of packages are in your Docker images, and your builds will be stable and reproducible.
| ) | ||
|
|
||
| def _generate_config(self, endpoint, metrics, namespace): | ||
| metrics = construct_metrics_config(metrics) |
There was a problem hiding this comment.
🟠 Code Quality Violation
variable name is the same as a function parameter (...read more)
A function parameter should only be read and not be modified. If your intent is to modify the value of the parameter, return the value in the function and handle the new value in the caller of the function.
What does this PR do?
New integration to monitor Patroni clusters
Motivation
What inspired you to submit this pull request?
No Patroni integration currently available
Review checklist
no-changeloglabel attachedAdditional Notes
Anything else we should know when reviewing?
Draft PR, will merge into a cleaner branch prior to requesting review