10GB stuck processing decomposeds3 opencloud

[suse-coder]

Describe the bug

I have minio + opencloud (decomposeds3) and one 10GB is since a very long time stuck in processing. Why is that and how to get around this. Is storageusers the pod responsible for that?

Is it true that max 5GB can be uploaded in one go with storageusers (throught that Multipart can do that). Are these settings correct or do they need to be changed?

disableMultipart: false
sendContentMD5: true
concurrentStreamParts: true
numThreads: 4
partSize: 0

[suse-coder]

Guess I need to go into pod storageusers and do: opencloud storage-users uploads sessions
--expired=true
--clean

[suse-coder]

Why is it that when I remove the storageusers data volume (delete it) and recreate container + volume, that even though the data was successfully uploaded to S3 that nothing is shown in the UI anymore? Shouldn`t storageusers be state less when everything with state is done over keycloak, ldap and S3?

[suse-coder]

I have used : opencloud storage-users uploads sessions
--clean

to remove it but it still is greyed out (even though not on the storage-users uploads list), how to see why and how to remove?

[micbar]

@suse-coder

The storageusers pod is NOT stateless when you use decomposedS3. S3 cannot store metadata like file identifier and share information. When you lose the storage users data, you lose all data from S3.

Minio has an upload limit which you can overcome via multipart upload, that is correct.

I don’t have the config at hand, but this is on the backlog for the docs team.

If files are running into errors during S3 upload, they are not lost. They are stored in the upload folder of the storage users data volume. The size of that volume limits the max upload size.

Uploads can always be restarted and resumed.

Successful uploads which are stuck in postprocessing can be restarted.

Is that restart job already part of the charts?
@butonic @wrenx

[suse-coder]

Should be documented in the docs