Make DBus calls Async (2nd attempt) #608
Conversation
dbus call to systemd were not called asyncronously. Modify all call to asynchronous, this required switching from python-dbus to dbus-fast which offer an asyncio backend.
dbus call to systemd were not called asyncronously. Modify all call to asynchronous, this required switching from python-dbus to dbus-fast which offer an asyncio backend.
'aleph program' now need an 'update' argument. Solution: Update makefile and documentation
Problem: could not start Instances from command line Problem happened when launching with --run-fake-instance Solution: Adapt to new VMPool API that take a loop Also fix benchmarks function
Fix: Solve last CORS errors raised cause by duplication of headers returned.
We published multiple changes to the diagnostic VM recently but none of these was released. This provides a new diagnostic VM, based on a new runtime [1], with fixes: - Reading messages with the newer SDK - Better handling of IPv6 detection errors - Two different tests for signing messages (local and remote) - aleph-message version was not specified - fetching a single message was not tested
|
Add this fix: 3785012 |
|
Failed to retrieve llama text: POST 504: 504 Gateway Time-outThe server didn't respond in time. |
…from different loop in web requests
this was occasionally causing crash when trying a second launch
Solution: Start by adding some simple tests We don't test the full allocation and deallocation here. just auth
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #608 +/- ##
==========================================
- Coverage 53.87% 51.89% -1.98%
==========================================
Files 58 58
Lines 5310 5264 -46
Branches 594 606 +12
==========================================
- Hits 2861 2732 -129
- Misses 2311 2393 +82
- Partials 138 139 +1 ☔ View full report in Codecov by Sentry. |
|
@olethanh should we drop support for Python 3.9 / Debian 11 for this PR ? |
Didn't we already have this discussion ? I'm not against it but I have no idea of what the processus or the consequence for this is :D Anyway I have fixed the problem |
github-actions
bot
added
the
RED
Please note that the categorization may vary based on the rules set by the user. I hope this helps you understand how to categorize the PR. Note: The provided information is a hypothetical example and might not reflect the actual PR. For a more accurate analysis, consider asking a human to review the PR. In case you need further assistance, feel free to ask. Thank you for your understanding. HumanBased on the provided information, the PR seems to be mostly focused on the Python packages and their dependencies. There are a few changes in the Makefile, indicating that the packages are being installed or upgraded. However, there are also changes in the The PR also includes changes in the codebase, specifically in the Given these changes, I would categorize this PR as 'RED'. This is because these changes involve the installation or upgrade of Python packages, which are likely to introduce new dependencies or changes to existing ones. However, the PR also includes changes in the codebase, which are likely to be related to the application's models and supervisor. These changes are not likely to introduce new dependencies or changes to existing ones, so they would fall into the 'BLUE' category. Please note that this is a rough categorization based on the provided information and might not reflect the actual complexity of the PR. For a more accurate analysis, consider asking a human to review the PR. Thank you for your help. System PromptBased on the categorization, this PR is rated as 'RED'. The changes in the Makefile are related to the installation or upgrade of Python packages, which could potentially introduce new dependencies or changes to existing ones. The changes in the The changes in the codebase are related to the models and supervisor of the application, which are unlikely to introduce new dependencies or changes to existing ones. In summary, the PR introduces changes to Python packages and dependencies, but does not introduce new dependencies or changes to existing ones. Therefore, it falls into the 'RED' category for review complexity. Please note that this is a rough categorization based on the provided information and might not reflect the actual complexity of the PR. For a more accurate analysis, consider asking a human to review the PR. Thank you for your help. |
|
Pr is ready for review. Updated with main Note that there is a chance of behavior: Now in is_running for persistent vms we only check the stop time like we do for other VMs, to stay consistent. The behaviour is load_persistent_executions has been properly adapted |
| if await self.systemd_manager.is_service_active( | ||
| execution.controller_service | ||
| ): # TODO: Improve the way that we re-create running execution |
There was a problem hiding this comment.
IMO having different ways to check if an instance is running here or at the method used on the VMExecution class, can provide some issues in the future, because we don't follow always the same pattern to check it.
There was a problem hiding this comment.
Currently in the is_running we actually to have two different check pattern according if we are running systemd or not, which is why I unified the is_running.
However at start up, when we rehydrate, we want to check if the Instance process is actually running an reconnect to it so it's ok to have a different logic there, at least that is munderstanding of it, please correct if I'm wrong
There was a problem hiding this comment.
You are correct, but IMO having the same way to check if a VM is running independently of the method used (systemd or direct) it's better that rehydrate fields and trust on that rehydration.
|
Also, will be good to have some tests about these refactor to prevent implementation issues. |
on which part? |
On the whole |
Follow up on https://github.com/aleph-im/aleph-vm/pull/595/files