Swarming: Removes Unnecessary DB calls#5223
Conversation
IvanBM18
added
the
swarming
| def is_swarming_task(job_name: str, job: data_types.Job | None = None) -> bool: | ||
| """Returns True if the task is supposed to run on swarming.""" | ||
| if not FeatureFlags.SWARMING_REMOTE_EXECUTION.enabled: | ||
| logs.info('[DEBUG] Flag is disabled', job_name=job_name) |
There was a problem hiding this comment.
Note: Theres no debug severity level in the logs module. I tried adding it but the logs were not being shown in the GCP log explorer when in debug, i guessed thats why didn't had said severity level in the first place
There was a problem hiding this comment.
You can use warning for this kind of debug log.
There was a problem hiding this comment.
I feel like moving it up to warning can be very noisy, for something that its not really a warning but more of a note for knowing why a given task ended up in swarming.
I'll instead fromat the logs as logs.info('[Swarming DEBUG] ....') this way it doesnt look as odd.. while we can still search for them :D
|
@jardondiego could you review it before I do? |
|
As discussed offline, I was under the understanding that we would focus only on the changes that are needed the most to finalize the integration, I am okay with moving forward but I suggest we prioritize that work instead. |
|
Please fix failing checks. |
This checks are failing due to external reasons as per @javanlacerda : "We're aware on this issue, we'll be addressing it soon. you can ignore for now" |
javanlacerda
left a comment
javanlacerda
left a comment
There was a problem hiding this comment.
LGTM. Did you manage to see the logs with the new schedule stage in dev? Could you attach it here?
| def is_swarming_task(job_name: str, job: data_types.Job | None = None) -> bool: | ||
| """Returns True if the task is supposed to run on swarming.""" | ||
| if not FeatureFlags.SWARMING_REMOTE_EXECUTION.enabled: | ||
| logs.info('[DEBUG] Flag is disabled', job_name=job_name) |
There was a problem hiding this comment.
You can use warning for this kind of debug log.
Co-authored-by: Javan Lacerda <javanlacerda@google.com>
Sure, heres a log with the |
3 participants
We are adding back the last batch of the changes that were rollbacked which make sure that we weren't making a lot of unnecessary calls into the DB. By consequence the signature of multiple methods were changed to simplified.
I also added a new tests to avoid the previous issue (the one that caused the rollback) from ever appearing again. This tests are in its own test class and its purpose is to check that the BadConfigError is correctly handled when no config is found(which is the expected bahaviour in the external and google envs)
Tests performed in
devenvironmentThis changes have been present since March 25th. Its been over one week since then and metrics seem consistent
Note: Down times in fuzzing hours matches when we deployed a change into the env.
Also no new error groups seem to be appearing in swarming, the only notable error is one relating missing permissions for uploading a test case, which seems unrelated
This changes have been in
devfor quite some time and we have successfully tested their functionality without compromising any functionality. For example this Task was scheduled with this changes.