On Thu, May 27, 2021 at 9:45 AM Willian Rampazzo wrote: > On Wed, May 26, 2021 at 8:41 PM Cleber Rosa wrote: > > > > On Wed, May 26, 2021 at 05:56:01PM -0300, Willian Rampazzo wrote: > > > The current host for the image > > > Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz > > > (archive.armbian.com) is extremely slow in the last couple of weeks, > > > making the job running the test > > > > tests/system/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_bionic_20_08 > > > for the first time when the image is not yet on GitLab cache, time out > > > while the image is being downloaded. > > > > > > This changes the host to one faster, so new users with an empty cache > > > are not impacted. > > > > > > Signed-off-by: Willian Rampazzo > > > --- > > > tests/acceptance/boot_linux_console.py | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/tests/acceptance/boot_linux_console.py > b/tests/acceptance/boot_linux_console.py > > > index 276a53f146..51c23b822c 100644 > > > --- a/tests/acceptance/boot_linux_console.py > > > +++ b/tests/acceptance/boot_linux_console.py > > > @@ -804,7 +804,8 @@ def test_arm_orangepi_bionic_20_08(self): > > > # to 1036 MiB, but the underlying filesystem is 1552 MiB... > > > # As we expand it to 2 GiB we are safe. > > > > > > - image_url = ('https://archive.armbian.com/orangepipc/archive/ > ' > > > + image_url = ('https://armbian.systemonachip.net/' > > > + 'archive/orangepipc/archive/' > > > > Hi Willian, > > > > I was pretty annoyed by my pipeline failures, that I came up with: > > > > > https://gitlab.com/cleber.gnu/qemu/-/commit/917b3e376e682e9c35c6f7f597ffca110c719e13 > > > > To prove that it was a GitLab <-> archive.arbian.com issue. > > When I tried both links, the slow link, and this new link, on my > machine, I could see the slow link is also slow locally. Not as slow > as on GitLab, but 10 times slower than this new link. I was thinking > about open an issue on GitLab. In the worst case, they will say it is > not their fault, but a problem on the other end. > > > But I wonder: > > > > 1. how susceptible to the same situation is this other mirror? > > Unfortunately, having tests depending on external artifacts will bring > this kind of situation. Unless GitLab is doing traffic shaping, we > will never know how susceptible an external server is to any kind of > instability. > > > 2. how trustworthy is this mirror, say, stability wise? Maybe > > people in the armbian community would have some info? > > This new link is the same link that > https://www.armbian.com/orange-pi-pc/ "Archived versions" is pointing, > so I consider it an official mirror from Armbian. That's why I have > not thought much about changing it. > > Now, stability wise, we never know :) I don't think we have this > answer for any of the links related to external artifacts QEMU > acceptance tests use. > > > > > Depending on the feedback we get about, this can be a very valid > > hotfix/workaround indeed. But the core issues we need to look into > > are: > > > > a. applying a timeout when fetching assets. If the asset fails to be > > fetched within the timeout, the test simply gets canceled. > > But this is failing during the download before the test starts, or in > the pre-phase. The test suite was not created and Avocado don't have a > mapping asset <=> test yet. > > Right. But my point is that if it times out, then this "best effort" attempt would fail (but not abort the job). Then, during the test itself, considering `cancel_on_missing=True`, the test would also cancel when it fails to access the asset. A canceled test is what we want here, and not a stuck job. That's why I still think the timeout may be a solution. Thanks, - Cleber.