daviftorres commented on issue #6647: URL: https://github.com/apache/cloudstack/issues/6647#issuecomment-3144705118
Yes, I do have one client who reported today the same issue described in "step 3" by the original author (who suspected a network failure or an issue on the HTTP server). <img width="1493" height="270" alt="Image" src="https://github.com/user-attachments/assets/395c7aa8-3182-46b7-9a5d-9aea0fc00fcd" /> In this case, I confirmed the problem was indeed on the HTTP server side: the file failed to download from three different sources simultaneously, and I was also unable to download it manually. On the SSVM, there's no visible activity from a Java application, and the download progress remains frozen at the same value, it doesn't timeout or retry. <img width="714" height="387" alt="Image" src="https://github.com/user-attachments/assets/440fbd6c-51e6-410c-9d18-ff2ffa22205e" /> To test how the system handles recovery, I re-deployed the SSVM in one of the zones. As expected, the system quickly detects that the SSVM is not up: <img width="1058" height="222" alt="Image" src="https://github.com/user-attachments/assets/65e07476-60b0-4650-b52c-682fbc6003ab" /> However, the status provided does not indicate what it's about to do next: <img width="1022" height="222" alt="Image" src="https://github.com/user-attachments/assets/357c7144-048b-4054-90c7-66741345b76e" /> Finally, it retries the download. As expected, this attempt also fails because the source is still unreachable. Yesterday, I had a similar scenario where the source was available, and the same procedure (re-deploying the SSVM) worked successfully. <img width="1023" height="219" alt="Image" src="https://github.com/user-attachments/assets/9a2d18df-0fe6-4450-9841-a759268556e7" /> @nvazquez, does this clarify your question regarding "step 3"? I still have the SSVMs in the other two zones running, let me know if you’d like me to collect specific logs that could be helpful. In summary: the goal here isn’t to fix a bug in the SSVM itself, but to improve its resilience against external failures and ensure it can fail gracefully if self-healing isn’t possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org