Open bedeho opened 1 year ago
Found another Argus issue:
Fantastic! Does Argus have any test iinfra we can add cases to for these bugs?
Fantastic! Does Argus have any test iinfra we can add cases to for these bugs?
In mono-repo integration tests we have Argus Api class which is used (as a dependency of content-directory integration-tests) to test content upload & delivery in integration tests. So basically you can think of this as indirectly testing the expected behavior of Argus if everything is working fine.
However, the integration-tests suite does not include any negative test cases for Argus Api(to test invalid input or external exceptions)
So we extend the Argus tests flow to test the API for all public endpoints when some/all of the external dependencies are not working, (e.g. QN/RuntimeApi etc.)
In your opinion, does Argus need its own standalone integration tests or unit tests, or should we just keep reyling on network tests?
In your opinion, does Argus need its own standalone integration tests or unit tests, or should we just keep reyling on network tests?
I think test cases for Argus can be added to network-tests
with minimal effort since all the supporting infra for tests is already there. However, considering the fact that we are having discussions about moving Argus into a separate repo, it makes sense to have a standalone test suite for Argus. This would also help in easily setting up the integration-tests CI checks in the Argus repo that can be configured to run for each PR, commit, etc.
Given that we now have publishable docker images for the Argus,Colossus and Query Node I propose that operators switch to using these images rather than running from mounted volumes from the monorepo. This allows easier deployment and ability to upgrade/downgrade the version running.
Additionally I propose that we do an incremental release approach, rather than bundling all new features into a single release.
Background
Based on excellent work from @kdembler as new distributor lead, pioneering work on improving content delivery system based on production observations, there is now a small catalogue of initial bugs and enhancements to bugging and features that he believes will improve the operation of the CDN.
It currently includes
New scope (added on July 26 2023)
Proposed Versions and Changelogs
Credit ls also goes to storage lead on the last issue!
Proposal
On the face of it, all of these likely have quite small fixes, and they tackle perhaps one of the most important parts of what will hold back the UX of Joystream apps at the moment, so ROI will be large. For this reason I believe it has a great ROI to map out how to remedy this and execute on these plans as soon as possible. It likely is operationally simplest to roll all of these into one release, called
origo
, so that we can have one QA and deployment process.I suggest @zeeshanakram3 as the lead on this release, and that the following steps are taken
Question
Origo
will likely be well beforeNara
, so there needs to be coordination on how to do this work while minimizing later reconcillioation. Basically tehre is a question of what snapshotOrigo
should use, @mnaamani can weigh in here.