Chapter 5. Known issues

When updating your Cryostat Operator subscription from Cryostat 2.0 to Cryostat 2.1, you must change the update channel from stable-2.0 to stable.

After this upgrade process, some Red Hat OpenShift objects that were created by the OpenShift Operator from Cryostat 2.0 will contain some outdated definitions. These definitions can result in connection issues among Cryostat components when you interact with your Cryostat 2.1 instance.

Remove Cryostat 2.0 services and deployments that exist in your Cryostat 2.1 instance.

oc project <cryostat_project>
cryostats=$(oc get cryostat --template \
  '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
for cryostat in ${cryostats}; do
  oc delete svc,deploy -lapp="${cryostat}"
done

After you remove these definitions, your Cryostat Operator creates services and deployments by using the Cryostat 2.1 object definitions. This restores connectivity among Cryostat components, and preserves JFR recordings that were created by Cryostat 2.0 in Cryostat 2.1.

Cryostat 2.1 does not concurrently handle API requests, which can lead to performance issues for your Cryostat instance.

In the following diagrams, the following symbols indicate actions:

An issue occurs under the Archived Recordings table on the Recordings menu item, when you re-upload a file with an identical file name to a file that already exists on the table.

If you attempt to delete or edit your re-uploaded file with this known issue, Cryostat applies the changes to both files. These changes can impact how you interact with the files, because you might be using Cryostat to analyze the incorrect file.

The following directory structure example shows the 20220401T212052Z.jfr archive recording file in a storage location that corresponds to the selected target JVM, archive. When you re-upload an identically named file from your local system to Cryostat’s archives location, Cryostat stores the file in a storage location that does not correspond to any target JVM, unlabelled .

archive/
├── file-uploads
├── ONSXE5TJMNSTU2TNPA5HE3LJHIXS6L3KNZSGSL3SNVUTULZPMNZHS33TORQXIORZGA4TGL3KNV4HE3LJ
│   └── es-andrewazor-demo-Main_foo_20220401T212052Z.jfr
└── unlabelled
        └── es-andrewazor-demo-Main_50mb_20211224T172734Z.2.jfr
        └── es-andrewazor-demo-Main_50mb_20211224T172734Z.jfr
        └── es-andrewazor-demo-Main_foo_20220401T212052Z.jfr

Based on the previous example, the current behavior of the re-upload operation on the Archived Recordings table shows two files with the same name. Cryostat applies the same name to both files, because Cryostat identifies each file as having different storage locations.

The expected behavior of the re-upload operation on Cryostat would append a subsequent number to the re-uploaded file. This means that this file does not share the same name as the file that exists before it in the table.