feat(s3): file metadata storage modes#927
Conversation
andrewazores
force-pushed
the
s3-object-tagging
branch
from
5bcea84 to
a729541
Compare
|
/build_test |
|
Workflow started at 5/21/2025, 4:53:24 PM. View Actions Run. |
|
No GraphQL schema changes detected. |
|
No OpenAPI schema changes detected. |
|
CI build and push: All tests pass ✅ |
|
/build_test |
|
Workflow started at 5/22/2025, 12:10:49 PM. View Actions Run. |
|
No OpenAPI schema changes detected. |
|
No GraphQL schema changes detected. |
|
CI build and push: All tests pass ✅ |
andrewazores
force-pushed
the
s3-object-tagging
branch
from
3e4e60f to
4f3f26b
Compare
|
/build_test |
|
Workflow started at 5/22/2025, 3:38:38 PM. View Actions Run. |
|
No GraphQL schema changes detected. |
|
No OpenAPI schema changes detected. |
|
CI build and push: All tests pass ✅ |
andrewazores
changed the title
andrewazores
force-pushed
the
s3-object-tagging
branch
from
58630de to
c43403e
Compare
|
/build_test |
|
Workflow started at 5/23/2025, 11:11:26 AM. View Actions Run. |
|
No OpenAPI schema changes detected. |
|
No GraphQL schema changes detected. |
|
CI build and push: All tests pass ✅ |
andrewazores
changed the title
andrewazores
force-pushed
the
s3-object-tagging
branch
from
1456bd0 to
a25db95
Compare
andrewazores
force-pushed
the
s3-object-tagging
branch
from
7cb1b1f to
211e352
Compare
|
/build_test |
|
Workflow started at 5/28/2025, 10:52:05 AM. View Actions Run. |
|
No OpenAPI schema changes detected. |
|
No GraphQL schema changes detected. |
|
CI build and push: All tests pass ✅ |
|
/build_test |
|
Workflow started at 6/12/2025, 12:02:14 PM. View Actions Run. |
|
No OpenAPI schema changes detected. |
|
No GraphQL schema changes detected. |
|
CI build and push: All tests pass ✅ |
Josh-Matsuoka
left a comment
Josh-Matsuoka
left a comment
There was a problem hiding this comment.
Tested the following via smoketest with all 3 storage modes (CRYOSTAT_STORAGE_MODE=tagging/metadata/bucket) using the cryostat-quarkus-agent test application and cryostat itself.
- Creating recordings
- Archiving recordings
- Stopping/deleting active recordings (both manually started and ones that started automatically)
- Deleting archived recordings
- Generating reports for recordings
- Uploading/using custom event templates
Everything looks good and works as expected.
|
/build_test |
|
Workflow started at 6/18/2025, 4:56:44 PM. View Actions Run. |
|
No OpenAPI schema changes detected. |
|
No GraphQL schema changes detected. |
|
CI build and push: All tests pass ✅ |
2 participants
Welcome to Cryostat! 👋
Before contributing, make sure you have:
mainbranch[chore, ci, docs, feat, fix, test]To recreate commits with GPG signature
git fetch upstream && git rebase --force --gpg-sign upstream/mainFixes: #924
Related to #269
See also cryostatio/cryostat-helm#247
See also cryostatio/cryostat-operator#959
Description of the change:
ArchivedRecordings(API endpoints) intoRecordingHelper(general utility) to ensure consistent behaviourstagging | metadata | bucket, and a "metadata bucket name". There are also sub-configurations for the "archived recordings storage mode" and "event templates storage mode" which accept the same values, and default to the overall metadata storage mode, which can be used to configure these two things differently if that is needed for some reason.tagging, Cryostat behaves the same as before this PR - metadata is stored in the S3 object Tags.metadatathen metadata is stored in the S3 object metadata.bucketthen the metadata bucket name must also be specified, and then Cryostat will not use object Tags but will instead use a separate storage bucket and create JSON files containing Metadata objects. Within the bucket the subdirectories and filenames mirror the actual archives so that the same file name "key" can be used to reference either the actual recording or its metadata depending on which bucket is queried.StorageBucketsimplementation so that declarative configuration startup activities do not proceed until the corresponding storage bucket (if any) has been successfully created. This prevents a race where Cryostat might try to ex. upload a custom event template into storage, before there is a bucket ready to receive that upload.BufferedInputStreamwrappers around S3 SDKstorage.getObject()responses and around declarative configuration file reads. The S3 SDK response ones are particularly important, because the S3 SDK HTTP client will reuse HTTP connections to reduce overall resource consumption, but connections cannot be released until the innerInputStreamhas been consumed/closed. Since there are internal operations that operate over these streams, such as by parsing them as XML documents, it's best to try to read the content out of the stream as quickly as possible and close it, so that the HTTP connection can be reused for another S3 SDK request.DefaultBeanandNamedannotationsMotivation for the change:
Circumvents the following potential problems with some S3 providers:
How to manually test:
CRYOSTAT_STORAGE_MODE=tagging ./smoketest.bash -O -s minio -t quarkus-cryostat-agentto run a smoketest using the standardtaggingmetadata storage behaviour.CRYOSTAT_STORAGE_MODE=metadata ./smoktest.bash -O -s minio -t quarkus-cryostat-agentto run a smoketest using metadata storage behaviour.CRYOSTAT_STORAGE_MODE=bucketto run a smoketest using bucketed metadata behaviour.Resource Types vs Storage Modes: