Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container with Elasticsearch #2550

Merged
merged 20 commits into from
Oct 31, 2024
Merged

Container with Elasticsearch #2550

merged 20 commits into from
Oct 31, 2024

Conversation

drosetti
Copy link
Contributor

(Please add to the PR name the issue/s that this PR would close if merged by using a Github keyword. Example: <feature name>. Closes #999. If your PR is made by a single commit, please add that clause in the commit too. This is all required to automate the closure of related issues.)

Description

Please include a summary of the change and link to the related issue.

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue).
  • New feature (non-breaking change which adds functionality).
  • Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist

  • I have read and understood the rules about how to Contribute to this project
  • The pull request is for the branch develop
  • A new plugin (analyzer, connector, visualizer, playbook, pivot or ingestor) was added or changed, in which case:
    • I strictly followed the documentation "How to create a Plugin"
    • Usage file was updated.
    • Advanced-Usage was updated (in case the plugin provides additional optional configuration).
    • I have dumped the configuration from Django Admin using the dumpplugin command and added it in the project as a data migration. ("How to share a plugin with the community")
    • If a File analyzer was added and it supports a mimetype which is not already supported, you added a sample of that type inside the archive test_files.zip and you added the default tests for that mimetype in test_classes.py.
    • If you created a new analyzer and it is free (does not require any API key), please add it in the FREE_TO_USE_ANALYZERS playbook by following this guide.
    • Check if it could make sense to add that analyzer/connector to other freely available playbooks.
    • I have provided the resulting raw JSON of a finished analysis and a screenshot of the results.
    • If the plugin interacts with an external service, I have created an attribute called precisely url that contains this information. This is required for Health Checks.
    • If the plugin requires mocked testing, _monkeypatch() was used in its class to apply the necessary decorators.
    • I have added that raw JSON sample to the MockUpResponse of the _monkeypatch() method. This serves us to provide a valid sample for testing.
  • If external libraries/packages with restrictive licenses were used, they were added in the Legal Notice section.
  • Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
  • I have added tests for the feature/bug I solved (see tests folder). All the tests (new and old ones) gave 0 errors.
  • If changes were made to an existing model/serializer/view, the docs were updated and regenerated (check CONTRIBUTE.md).
  • If the GUI has been modified:
    • I have a provided a screenshot of the result in the PR.
    • I have created new frontend tests for the new component or updated existing ones.
  • After you had submitted the PR, if DeepSource, Django Doctors or other third-party linters have triggered any alerts during the CI checks, I have solved those alerts.

Important Rules

  • If you miss to compile the Checklist properly, your PR won't be reviewed by the maintainers.
  • Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review. After being reviewed and received a "change request", you should explicitly ask for a review again once you have made the requested changes.

@drosetti drosetti requested a review from mlodic October 22, 2024 16:49
@drosetti drosetti marked this pull request as draft October 22, 2024 16:53
@drosetti
Copy link
Contributor Author

I converted the pr to draft because the doc is missing

@drosetti drosetti marked this pull request as ready for review October 23, 2024 09:12
@drosetti
Copy link
Contributor Author

restored to real pr, the doc is in another repo

Copy link
Member

@mlodic mlodic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is important to write in the docs which elasticsearch versions are supported / have been tested


def _convert_report_to_elastic_document(_class: AbstractReport) -> List[Dict]:
upper_threshold = now().replace(second=0, microsecond=0)
lower_threshold = upper_threshold - datetime.timedelta(minutes=5)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

timedeltas should not be calculated inside async functions but should be calculated beforehand. That is to avoid that, in case of congestion, this value changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's correct to calculate it inside the task: the alternative is to put it in the beat schedule, but this doesn't work because the function is called once when the schedule is defined and the time range would be the same for all the scheduled tasks. Am i wrong ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, you right. If I remember correctly, in another occasion we managed this case by calculating the time from an element of the database. In this way there's no way of getting this value wrong because this task would change it only at the time of execution. So, if there are any downtimes, there would be no loss of data. (I am afraid of having the sync misaligned cause we lose some data from time to time. That would make data analysis really bad)

(I would still get the time from "now" first and then, instead of doing minus 5 minutes, I would use as lower_threshold the data got from the database of the last update)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, I remember what are you talking about, but I didn't find collections: I found some capped collections used to repeat a task in case of failure, it's similar, but not the same. However I found a way to do it with postgres, I proceed with the merge.

Copy link
Contributor

@code-review-doctor code-review-doctor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Worth considering though. View full project report here.

api_app/models.py Show resolved Hide resolved
@drosetti drosetti merged commit 4220e7e into develop Oct 31, 2024
11 of 12 checks passed
@drosetti drosetti deleted the advanced-queries branch October 31, 2024 15:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants