Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3891
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

The code LGTM, but I wonder if we wouldn't be better served if we instead change the logic that was generating the original problematic messaging in #3890.

Unless I overlooked something this function is what ends up generating both parts of the message: the missing case id; the upload to Red Hat Secure FTP.

It would strike me as a little strange for the RH api path the be appended on to whatever endpoint/bucket path I'd otherwise be expecting.

Only included this as I think @jcastill mentioned RH potentially using an S3 bucket in the future. I presume he may be adding an RH_S3_HOST (aka an S3 Endpoint) in the work he is doing separately.

I want to be sure I understand your request. When both a case id and a bucket prefix are provided the resulting sos-collector tar archive will contain the case id, but the archive itself is only found inside the provided s3 object prefix? Or are you suggesting we drop the rh_case_api altogether and if the user provides a case id without providing an object prefix the tar file, with a case ID in its name, ends up in the root of the bucket?

Thanks in advance for any clarification.

Let me answer this way, please let me know if I'm not making sense here.

As an end-user creating an sos report and uploading it to an S3 location that I've defined in my config file or in the sos command I'm running, I would expect:

• No message about SFTP, regardless of it a case id was provided or not
• No message about a Red Hat location
• The sos report to end up in the endpoint/bucket I defined, and not nested under a path I did not specify.

On that last point that means I'd expect, with or without a case id, this path from #3890:

s3://project-sosreports/ba59c727-bfd2-4808-8f5f-f62c63903c13/2024/12 or, potentially, s3://project-sosreports/ba59c727-bfd2-4808-8f5f-f62c63903c13/2024/12/$case_id

and not

s3://project-sosreports/support/v1/cases/12345/attachments

If RH starts using an S3 bucket, we'd address any handling of that within the Red Hat upload methods so that it doesn't impact a user uploading to a non-RH S3 location in any way. We really need to separate upload from policy, and I'll try and spend some time on that this week and next - but for the purposes of this PR I'm mainly just concerned about the above - predictable and expected locations within a user-specified S3 destination.

Makes sense and clarifies the case of no prefix with a case id, which will result in the path: s3://project-sosreports/$case_id.

I'll make the adjustments and force push a new commit for review.

I thought providing an https:// based upload_url that includes the endpoint would be more informative. On further review I see why I used the s3:// url instead:

The upload_s3 method doesn't rely on upload_url currently, so get_upload_url returning a string w/ case_id appended shows the Attempting upload to correctly, but its dropped by the upload process.

While appending the case_id to the object prefix seemed a simple fix to this I found on a freshly installed rhel 8.9 system get_upload_url() method of RHELPolicy is called multiple times, or recursively. This lead to the case_id being appended more than once when appending it directly to the s3 object prefix instead of the upload_url.

[RHELPolicy.get_upload_url] called
[RHELPolicy.get_upload_url] called
[RHELPolicy.get_upload_url] called
[RHELPolicy.get_upload_url] called
Attempting upload to https://sosreport.example.com/project-sosreports/ba59c727-bfd2-4808-8f5f-f62c63903c13/2024/12/12345/12345

I'm going to convert this PR to a draft while determining how best to implement the requests and if aligning s3 more closely to the other upload protocols logic is possible.