I am working on this bug and I could not reproduce. I tested with the overload environment: 200 share servers (each one with one share).
I ran a script to extend the size of each share (200). It worked finely (no timeout error). Also, I run that script without the utilization metrics (using the same approach to skip as [1]), it took the same time as with metrics.
Maurice, could you give more details ?
1. has the workaround provided by [1] fixed this bug ??? If so, we may improve the fix to cache instead of skipping.
2. Which operation is returning timeout error ??
3. Is it API, scheduler or share error ? If possible, provide the log for us
4. How is the environment: number of shares, servers and so on ?
Hi all,
I am working on this bug and I could not reproduce. I tested with the overload environment: 200 share servers (each one with one share).
I ran a script to extend the size of each share (200). It worked finely (no timeout error). Also, I run that script without the utilization metrics (using the same approach to skip as [1]), it took the same time as with metrics.
Maurice, could you give more details ?
1. has the workaround provided by [1] fixed this bug ??? If so, we may improve the fix to cache instead of skipping.
2. Which operation is returning timeout error ??
3. Is it API, scheduler or share error ? If possible, provide the log for us
4. How is the environment: number of shares, servers and so on ?
Thanks, Felipe.
[1] https:/ /github. com/sapcc/ manila/ commit/ cfeef704fc29214 71848fb1002678a 8b264887f5